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ABSTRACT 


A major component of the US Army’s Future Combat Systems (FCS) will be a 
fleet of eight different manned ground vehicles (MGV). There are promises that 
‘advanced automation’ will take on many of the tasks formerly performed by soldiers in 
legacy vehicle systems. However, the current approach to automation design does not 
relieve the soldier-operator of tasks; rather, it changes the role of the soldiers and the 
work they must do, often in ways unintended and unanticipated. This thesis proposes a 
coherent, top-down, overarching approach to the design of a human-automation 
interaction model. First, a qualitative model is proposed to drive the functional 
architecture and human-automation interface scheme on the MGV fleet. Second, 
proposed model is applied to a portion of the functional flow of the common crew station 
on the MGV fleet. Finally, the proposed model is demonstrated quantitatively via a 
computational task-network modeling program. The modeling approach offers insights 
into the impacts on human task-loading, workload, and human performance. 
Implications for other domains in human systems integration are discussed. The 
proposed model gives engineers and scientists a top-down approach to explicitly define 
and design the interactions between proposed automation schemes and the human crew. 
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EXECUTIVE SUMMARY 


A major component of the US Army’s Future Combat Systems (FCS) will be a 
fleet of eight different manned ground vehicles (MGV). There are promises that 
‘advanced automation’ will accomplish many of the tasks formerly performed by soldiers 
in legacy vehicle systems. However, the current approach to automation design does not 
relieve the soldier-operator of tasks; rather, it changes the role of the soldiers and the 
work they must do, often in ways unintended and unanticipated. This thesis proposes a 
coherent, top-down, overarching approach to the design of a human-automation 
interaction model. 

Given the available literature on design of automation and the need at BAE 
Systems (one of the defense contractors building the MGV fleet), a qualitative model is 
proposed to drive the functional architecture and the human-automation interface scheme 
on the MGV fleet. The model starts with a five-stage model of information processing for 
the human-automation interaction scheme in the FCS MGV fleet (Table 1). It stands 
squarely on the shoulders of a few giants in the field of human factors and automation 
research and development (Parasuraman, Sheridan, Wickens, 2000; Kaber & Endsley, 
2004). 

Table 1. Five-Stage Model of Information-Processing for Human-Automation 


Interaction Scheme in the FCS MGV Fleet 


Stage 

Definition 


Information 

Acquisition 

Acquisition and registration of multiple sources of 
information. Positioning and orienting of sensory receptors, 
sensory processing, initial pre-processing of data prior to 
full processing, and selective attention 

2 

Information 

Analysis 

Conscious perception and manipulation of processed and 
retrieved information in working memory. Also includes 
cognitive operations (rehearsal, integration, and inference) 
occurring prior to point of decisions. 

3 

COA Development 

Generating (a) the decisions that need to be made, followed 
bv (b) formulating options or task strategies for achieving 
goals. 
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Stage 

Definition 


Decision Selection 

Selection of a particular option, course of action (COA), or 
strategy to carry out. Decision(s) are reached based on the 
Analysis stage (cognitive processing), the COA 
Development stage, and expertise (human or software). 

5 

Action 

Implementation 

Consistent with the decision selection(s), carrying out the 
chosen option, COA, or strategy, whether through control 
actions at an interface or other means. 


The proposed human-automation interface model is shown graphically in Figure 
1. This demonstrates the five stages of information processing, as well as the possibility 
for ten levels of automation (LOA) within each of the five stages. It retains the 
intuitiveness of the original model from Parasuraman et al. (2000) while allowing system 
engineers and designers to explicitly define how the human and proposed automation will 
interact so we might be able to understand how the two will perform as part of the overall 
system in development. Functions A/A' and Systems B/B' will be provided as examples 
of how a human-automation interaction scheme might be designed conceptually. 












Figure 1. Qualitative Model for Design for Human-Automation Interaetion in the 

FCS MGV Fleet. Note how the UA ‘Quality of Firsts’ are related to the proposed 
model. 


Therefore, to further the ideals of this thesis, Figure 2 graphieally presents two 
possible human-automation interface schemes to achieve the common function of Local 
Defense. The current scheme (yellow line on the graph) employs almost no automation, 
only giving the vehicle commander some physical aids to allow arming and firing of the 
chosen weapon with a single button press. The vehicle commander is totally responsible 
for detecting, identifying, and tracking any local threats. In the Engagement stage, the 
commander must then make a series of decisions (probably in rapid order) that starts with 
whether to engage the target or not, followed by selections of the appropriate weapon and 
ammunition. At the Shoot/Report stage, automation design gives the commander some 
physical help by only requiring a simple button press to arm the chosen weapon, and then 
another single-button press to fire the weapon. Preparation and transmission of the 
digital (i.e., typed text) situation report is left completely with the commander. 
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FCS Manned Ground Vehicle Fleet (Common Crew Station) 
Local Defense (CFM 5): Acquire/Track/Enqaqe Threat (CFM 51-52) 



Figure 2. Qualitative Model Applied to the Loeal Defense Funetion 


This thesis implemented the qualitative model applied to the MGV via a 
eomputational analysis using task-network modeling and Monte Carlo simulation from a 
software package called IMPRINT, developed by the US Army Research Lab’s Human 
Research and Engineering Directorate. Using the proposed architecture in Figure 2, the 
Local Defense function of the MGV fleet was modified to reflect the new and resulting 
human-automation architecture by ‘dialing in’ selected levels of automation for selected 
tasks. 

Comparison of operator task-loading of the current systems vs. the proposed 
automation architecture shows that it is possible to reduce operator task-loading. A 
primary conclusion of the thesis is that by applying the proposed human-automation 
interface model to other functions in the vehicles, it is possible to make further reductions 
in operator task-loading and mental workload. This will also support attempts to achieve 
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the current ORX) requirement for a vehicle operable by a 2-soldier crew. This work is 
intended to contribute to the effort to ensure that vehicle systems in the MGV fleet can 
accomplish the overall unit mission and the PCS’ mission as an acquisition program. 
Even if we eventually conclude that an additional crewmember is required on the various 
MGV vehicles, the same qualitative and quantitative models can be used to gain a clear 
understanding of the human-automation interaction as well as the some of the human 
performance ramifications in terms of mental workload. 

With this tool in hand, the exact role of the Soldier operators as the central 
component of the vehicle systems is clearly understood well before the fielding of the 
vehicle systems. This is but one way (among several) to work toward the ORD 
requirement for a 2-soldier crew. But, even if the 2-soldier crew requirement is relaxed, a 
coherent plan for automation will help to ensure soldier performance and system 
effectiveness. The focus of the model is to ensure that a reduced-crew can perform well 
enough (not optimally) to accomplish all of the functions and tasks asked of the total 
vehicle system. 

The models and techniques proposed in this thesis have implications beyond just 
the PCS manned vehicle. The general model and analytical processes, or similar 
approaches, are certainly necessary in a slew of complex systems that lack an 
‘automation philosophy’ to guide the design of a proper interaction between human and 
automation to ensure total system performance. 
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I. INTRODUCTION AND BACKGROUND 

A. THE U.S. ARMY’S FUTURE COMBAT SYSTEMS (ECS) AND THE 

PROMISE OF AUTOMATION 

Future Combat Systems (FCS) is a joint, networked system of systems made up of 
18 individual systems, the network, and most importantly, the Soldier. FCS will be 
conneeted via an advaneed network arehiteeture that will enable levels of joint 
connectivity, situational awareness and understanding, and synchronized operations 
heretofore unachievable. FCS will operate as a System of Systems (SoS) that will 
network existing systems, systems already under development, and systems to be 
developed to meet the requirements of the Army’s Future Force Unit of Action (UA). 

FCS comprises 18+1+1 systems consisting of unattended ground sensors (UGS); 
two unattended munitions, the Non-Line of Sight - Launch System (NLOS-LS) and 
Intelligent Munitions System (IMS); four classes of unmanned aerial vehicles (UAVs) 
organic to platoon, company, battalion and Unit of Action (UA) echelons; three classes of 
unmanned ground vehicles, the Armed Robotic Vehicle (ARV), Small Unmanned 
Ground Vehicle (SUGV), and Multifunctional Utility/Logistics and Equipment Vehicle 
(MULE); and the eight manned ground vehicles (18 individual systems); plus the 
network (18+1); plus the Soldier (18+1+1) (US Army, 2005). 

BAE Systems (formerly United Defense, Limited Partnership [UDLP]) and 
General Dynamics Land Systems (GDLS) have been named the Vehicle Integrators (V.l.) 
for the manned ground vehicle (MGV) fleet of FCS. The V.l. team of BAE Systems and 
GDLS are jointly responsible for design, development, and production of the MGV fleet. 
The eight vehicles in the MGV fleet are: Mounted combat system (MCS), Infantry carrier 
vehicle (ICV), Non-line-of-sight cannon (NLOS-C), Non-line-of-sight mortar (NLOS- 
M), Reconnaissance and surveillance vehicle (RSV), Command and control vehicle 
(C2V), Medical vehicle (treatment and evacuation variants; MV-E and MV-T), and the 
FCS Recovery and Maintenance Vehicle (FRMV). Operating under a cooperative 
research and development agreement (CRADA) between the Naval Postgraduate School 


1 



(NPS) and BAE’s offices in Santa Clara, CA (BAE-SC), engineers at BAE have 
partnered with NPS to investigate human systems integration (HSI) issues related to the 
MGV fleet. 

BAE Systems is responsible for development and manufacture of several vehicles 
in the MGV fleet, as well as design of the common crew station (CCS) between all of the 
MGV fleet. The ECS Operational Requirements Documents (ORD; dated 31 January 
2005), requires that all ECS Manned Systems must be operable by a 2-man crew (a driver 
and vehicle commander), with the rationale being that the platform must be simple 
enough for a 2-man crew to operate effectively (US Army, 2005, p. D-7). The lone 
exception is the MCS, a tank-like vehicle which will have a three-person crew. The limit 
of two soldiers is an intense effort by the Army to gain significant life-cycle cost savings 
by eliminating costly manpower. Current armored vehicles in the Army fleet typically 
have at least 3-4 soldiers in the crew, sometimes more for certain artillery vehicles. 

Early design meetings for the ECS’ Warfighter-Machine Interface (WMI) have 
routinely promised that ‘advanced automation’ will assume many of the tasks formerly 
performed by soldiers in legacy vehicle systems. However, there does not appear to be a 
coherent plan to design the human-automation interface. Instead, various engineers have 
proposed a bottom-up process for automation, starting with a detailed task analysis for 
the common crew station, (personal communications, Jeffrey Powers, Dr. Patty 
Lakinsmith, Dr. Douglas Neil, [of BAE Systems], June 2005). Then the V.I. team will 
decide what tasks to automate based on technical feasibility, without regard to the overall 
human-automation interface scheme that would result. There are many talented, 
dedicated engineers and scientists working hard to generate ideas and designs for 
automation on the MGV fleet, but without any general philosophy or overarching design 
concept for automation. 

The overall ideas being proposed for a human-automation scheme are 
inappropriate based on past experience and lessons learned, literature reviews, and 
multiple transportation accidents (aircraft, cars, and trains). No coherent guide exists tot 
guide decision about what types or and how much automation. Without a reasoned plan 
for the functional architecture of automation design, any automation pieces added to a 
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complex system are not likely to relieve a human operator of tasks; it will merely shifts 
them from being manual tasks to more supervisory ones. Thus, the human operator must 
become a ‘super-supervisor’ in order to monitor and understand ever 5 dhing that is being 
automated. The MANPRINT/Human Faetors ehief at BAE confirms that the V.I. would 
benefit from an overarching guide to design the human-automation interface scheme 
across the MGV. 

Therefore, operating within a eooperative research and development agreement 
(CRADA) between NPS and BAE-SC, the goal of this thesis was to provide a proeess for 
developing a top-down, overarehing approaeh to explicitly define and design the 
interaetion between proposed automation sehemes and the human erew. It shows an 
approach to developing a functional architecture between human and automation for the 
total system. While it was developed for engineers and seientists at BAE and the V.I., the 
proeess can be expanded to a wide array of domains (aviation, spaee, maritime, ground 
transportation, manufaeturing, ete.). It ean be applied to the FCS MGV fleet to reduee 
operator workload and possibly improve erew performance. There are implieations for 
crew size in the total vehiele system. 


B. EXAMPLES OF HUMAN FAILURES DUE TO POOR AUTOMATION 

DESIGN 

There is a sizable researeh base examining human eapabilities (and subsequently, 
human error and failure) involved in work with automated systems. New technologies 
applied to the control of complex person-maehine systems ean have a significant impact 
on operator performanee and training requirements. While reviewing US Army air 
defense command and control, Hawley, Mares, and Giammaneo (2005, p. 3) noted that 
“the erux of the problem of new teehnologies applied to system control is that they tend 
to remove human operators from moment-to-moment, on-line eontrol and relegate them 
to the role of supervisory eontrollers. A variety of researeh has indicated that the 
consequences of this change are not always positive’’ (Hawley, Mares, & Giammaneo, 
2005). 
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Norman (1990) detailed the case of a fuel leak in a commercial airliner in which a 
vigilant second officer detected the signs of one possible problem, but failed to detect 
another. Here is a quote from the accident report, as reported in Norman’s paper (p. 6): 

Shortly after level off at 35,000 ft... the second officer brought to my 
attention that he was feeding fuel to all 3 engines from the number 2 tank, 
but was showing a drop in the number 3 tank. I sent the second officer to 
the cabin to check that side from the window. While he was gone, I 
noticed that the wheel was cocked to the right and told the first officer 
who was flying the plane to take the autopilot off and check. When the 
autopilot was disengaged, the aircraft showed a roll tendency confirming 
that we actually had an out of balance condition. The second officer 
returned and said we were losing a large amount of fuel with a swirl 
pattern of fuel running about mid-wing to the tip, as well as a vapor 
pattern covering the entire portion of the wing from mid-wing to the 
fuselage. At this point we were about 2000 lbs. out of balance.... 

In this example, the second officer (flight engineer) provided valuable feedback 
that something seemed wrong with the fuel balance. “The automatic pilot had quietly 
and efficiently compensated for the resulting weight imbalance, and had the second 
officer not noted the fuel discrepancy, the situation would not have been noted until much 
later, perhaps too late (1990, p. 6). Norman argued that “it is essential to examine the 
entire system: the equipment, the crew, the social structure, learning and training, 
cooperative activity, and the overall goals of the task. Analyses and remedies that look at 
isolated segments are apt to lead to local, isolated improvements, but they may also create 
new problems and difficulties at the system level’’ (1990, p. 2). 

The aviation realm contains numerous documented case studies and research 
findings that detail the coordination breakdown between flight crews and automation. 
Tools that were supposed to serve the human operators and provided ‘added 
functionality’ actually present new challenges in terms of human factors, usability, and 
training. Woods and Sarter (1998) capture the user’s perspective on the current 
generation of automated systems. It is best expressed by the questions they pose in 
describing incidents: “What is it doing now? What will it do next? How did I get into this 
mode? Why did it do this? How do I stop this machine from doing this?’’ (p. 5). 
Questions like this point to automation surprises. 
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A landmark paper from Parasuraman and Riley (1997) noted that designers tend 
to automate everything that leads to an eeonomie benefit and leave the operator to 
manage the resulting systems. “Teehnieal eapability and low cost are valid reasons for 
automation if there is not detrimental impact on human (and hence system) performance 
in the resulting system'" (emphasis added; p. 232). The need for better feedback about 
the automation’s states was revealed in a number of ‘controlled flight into terrain’ (CFIT) 
accidents, in which the crew selected the wrong guidance mode, and indications 
presented were similar to when the system was tracking the glide slope perfectly. For 
example, an Airbus 320 crashed in Strasbourg, France, when the crew apparently 
confused the vertical speed and flight path angle modes. “Unfortunately, the ability to 
address human performance issues systematically in design and training has lagged 
behind the application of automation, and issues have come to light as a result of 
accidents and incidents’’ (1997, p. 232). 


C. AUTOMATION IS NOT A PANACEA - MUST BE GUIDED BY AN 

ARCHITECTURE 

‘Advanced automation’ is frequently touted as a solution to accomplish tasks 
formerly performed by Soldiers, thereby allowing us to decrease the number of Soldiers 
manning a vehicle. The tendency has been to automate what is easiest and leave the rest 
to the operators. From one perspective, this dignifies the operators. However, it may lead 
to a “hodgepodge of partial automation, making the remaining human tasks less coherent 
and more complex than they would be otherwise be, and resulting in overall degradation 
of system performance’’ (Sheridan, 2002, 152). 

The former approach, unconsciously championed by many systems, electronics, 
and software engineers, does not relieve a Soldier of tasks. Rather, it merely shifts 
manual tasks to more supervisory ones. Automation aids do not “simply supplant human 
but rather changes it, often in ways unintended and unanticipated by the designers of 
automation, and a result poses new coordination demands on the human operator’’ 
(Parasuraman, Sheridan, & Wickens, 2000, p. 286-287). A soldier may become a 
‘super-supervisor’ trying to handle the leftover tasks as well as monitor that which has 
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been automated. The engineers’ motivation is threefold, albeit noble. First is to make the 
system simpler and cheaper to engineer. Second, is to relieve the human operator, to 
reduce mental workload. Third, is to the make the system safer. Yet automation can have 
just the opposite effect in all three categories (Bainbridge, 1983 as cited in Sheridan, 
2000 ). 

Vehicles in the MGV fleet will be complex systems with considerable technology 
advances. In some cases, the technology might enable the complete automation of certain 
subsystems, functions, and/or tasks. In many cases, however. Soldiers will still be very 
much involved in system operations. To combat the increasing complexity and serious 
potential for information overloads. Rouse, Geddes, and Curry (1987) argued that two 
methodological issues must be addressed (explicitly or implicitly) before beginning the 
development of a support system concept: choose a design methodology, and adopt an 
automation philosophy. 

Rouse et al. (1987) argue that any human-machine interface should involve a few 
common methodological ingredients: an understanding of the user-system interaction, 
human capabilities and limitations in performing the general tasks identified, and the 
potential barriers to using the interface. In addition, “use of advanced hardware and 
software technology should not be an end in itself; it should be the means to providing 
the desired functionality. At the highest levels, this desired functionality is dictation by 
the automation philosophy underlying the support system concept” (1987, p. 90). The 
automation philosophy is governed by the questions of when and how to automate, with 
the answers directly determining the roles of operators in systems. “The purpose of 
explicitly choosing an automation philosophy is to assure that the implications for 
operators’ roles are specific and acceptable prior to system design. This is important 
because the overall performance of complex systems depends heavily on human 
performance" (italics added; 1987, p.91). 

Rouse et al. caution against simply automating all that is possible, stating that 
“this technology-driven approach is understandable, but is increasingly unacceptable as 
the technology that is driving automation efforts becomes more likely to be 
incomprehensibly complex” (1987, p. 91). They argue for the adoption of an operator- 
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centered automation philosophy, which emphasizes human operators in control and 
technology that provides support, a concept that “requires a comprehensive architecture 
for an intelligent interface” (1987, p.92). 


D. STATEMENT OF THE PROBLEM 

The PCS MGV fleet lacks an overarching, top-down approach to its human- 
automation interface scheme. With the current methodology and design approach, it can 
be considered doubtful that performance from a 2-soldier crew will be acceptable, thus 
making the human and crew performance a major risk factor in overall system 
performance. Given the current ORD requirement for a 2-soldier crew, we must design a 
human-automation interface model that can be applied to the MGV common crew station 
(CCS) to increase the probability that a two-soldier crew will be able to perform well 
enough to accomplish all of the functions and tasks asked of the total vehicle system 
(hardware, software, and humans) as part of the Army’s Unit of Action (UA) doctrine. 

While this thesis focuses on ways to solve real technical issues in the PCS MGV 
fleet, the model and analytical processes proposed, or similar approaches, certainly are 
necessary in a slew of complex systems in multiple domains (aviation, space, maritime, 
ground transportation, manufacturing, etc.). As a thorough literature review reveals, there 
are very few people thinking about an ‘automation philosophy’ to guide the complex 
interactions between humans and automation to ensure total system performance. So 
while the proposals here were developed for the PCS MGV fleet, they are in no way 
limited to that particular application. 


E. PROPOSAL 

In response to the problem statement detailed above, a three-step solution is 
proposed. The first step is to develop a qualitative model to drive the functional 
architecture and the human-automation interface scheme on the MGV fleet. This is but 
one way (among several) to work toward the ORD requirement for a 2-soldier crew. But, 
even if the 2-soldier crew requirement is relaxed, a coherent plan for automation will help 
to ensure soldier performance and system effectiveness. The focus of the model will be to 
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ensure that a reduced-crew can perform well enough (not optimally) to accomplish all of 
the functions and tasks asked of the total vehicle system. 

The second step will be to apply the interface scheme against selected parts of the 
CCS function/task analyses (provided by BAE human factors specialists in their Santa 
Clara, CA office). The function/task analysis (FA/TA) provides an overall reference on 
how the Army and the V.l. envision the total vehicle system to operate. As such, the 
FA/TA is currently indifferent as to the allocation of functions and tasks between the 
hardware/software components of the system and the human crew. 

Lastly, it would beneficial to gain a quantitative understanding how the 
application of the qualitative model to a block of functions from the FA/TA will affect 
soldier performance in the common crew station. One way to quantify estimated human 
performance in a system still in conceptual design is to predict human mental workload 
via a task-network modeling program. In this case, we will model the updated task 
analysis in a modeling program called Improved Performance Research and Integration 
Tool (IMPRINT), provided by the US Army Research Laboratory’s Human Research and 
Engineering Directorate (ARL/HRED). IMPRINT allows analysts to quantify operator 
mental workload via prediction of task-loading in the proposed vehicle system, a key 
aspect of overall human performance (see ARL/HRED, 2005; Mitchell, 2000). The goal 
of this quantitative modeling will be to predict whether the new human-automation 
interface scheme, as modeled in IMPRINT, will lower operator task-loading predictions. 
If the mental workload score predictions are lower after apply the new model of human- 
automation interface, we can reasonably argue that careful, continued application of the 
new interface model may allow for satisfactory 2-soldier performance in the final system 
design. 

The proposed thesis will provide a top-down, overarching approach that enables 
engineers to explicitly define and design the interaction between proposed automation 
schemes and the human crew. In effect, it constitutes the design methodology and 
automation philosophy, as espoused by Rouse et al. (1987). With this tool in hand, the 
exact role of the Soldier operators as the central component of the vehicle systems is 
clearly understood well before the fielding of the vehicle systems. In this way, we can 
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take a step towards reducing workload peaks and improving human performance. It will 
also support attempts to achieve the current ORD requirement for a vehicle operable by a 
2-soldier crew. This work is intended to contribute to the effort to ensure that vehicle 
systems in the MGV fleet can accomplish the overall unit mission and the PCS’ mission 
as an acquisition program. 

F. METHODOLOGY OVERVIEW 

The methodology is described in four parts. First, it was necessary to conduct a 
comprehensive review of the Army’s doctrinal concepts for the Unit of Action and Unit 
of Employment (UA/UE). FCS is the materiel solution to meet the UA/UE concept of 
future warfare, or how the Army wants its soldiers and units to fight in the future. To 
understand the materiel requirements, it is vital to thoroughly understand the fighting 
doctrine that FCS is being built to achieve. 

The second major phase was to conduct a thorough review of the current ORD, 
the UA Operational and Organizational (O&O) Plan, the prime item development 
specifications (PIDS) and procurement control drawing (PCDs) for each of the vehicles 
being developed by the Army in conjunction with the Lead Systems Integrator (LSI) 
team of Boeing and SAIC. This family of doctrine, requirements, and specifications 
documents served to form the core of an overall ‘human-automation interface’ 
requirements listing and top-down requirements and functional analysis that was needed 
for the design phase of this thesis. Thus, the project required a thorough review in 
performing functional and task analyses (e.g., Kirwan & Ainsworth, 1992). Human 
factors specialists at BAE have already developed a fairly mature FA/TA for the common 
crew station (CCS), and developed a functional flow that was used in this project. 

The third phase was to conduct a thorough literature review of automation design 
methodologies, especially as they relate to potentially reducing manning requirements 
(Chapter II). Two great examples of the military Services attempting to use ‘advanced 
automation’ to gain manpower savings are the Army’s LHX helicopter program (which 
later became the RAH-66 Comanche), and the Navy’s DD-X program. This phase formed 
the basis for the qualitative model proposed in Chapter III. In short, a 5-stage model for 
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types and levels of automation is proposed, both in textual and graphical form. The 5- 
stage model was applied against a selected group of functions from the CCS FA/TA 
provided by engineers at BAE-SC. Primary sources for the qualitative model include 
Parasuraman, Sheridan, and Wickens (2000), Parasuraman (2000), Endsley and Kaber 
(1999), Kaber and Endsley (2004), Proud, Hart, and Mrozinski (2003), and Billings 
(1997). 

The fourth phase of the thesis was a quantitative task-loading analysis of the new 
human-automation interface in IMPRINT. Analysts with BAE-SC and ARL/HRED 
have developed a task-network model in IMPRINT using a set of functions common to 
the entire MGV fleet. Using their model as a baseline, I applied the proposed human- 
automation interface scheme to their selected portions common function model (CFM) to 
investigate whether predictions of total mental workload would decrease. This phase of 
the thesis was designed to demonstrate, quantitatively, how human task loading might be 
affected by a new human-automation interface scheme. 

The proposed human-automation interface scheme for the MGV fleet can 
contribute to multiple HSI and MANPRINT (Manpower and Personnel Integration) 
domains that will require trade-off analysis to resolve. We can anticipate impacts to 
nearly all of the domains, including Manpower, Personnel, Training, Human Factors 
Engineering, Soldier Survivability, and System Safety (see US DoDI 5000.2, pp. 32-33, 
and US Army Regulation 602-2 for details of the HSI/MANPRINT domains and their 
definitions). The potential HSI (MANPRINT) domain tradeoffs will be discussed in 
Chapter VI. 

G. DEFINITION OF TERMS 

A comprehensive list of acronyms appears on pages xiii-xv. However, there are 
several terms that must be defined now since they lie at the heart of the problem 
statement, methodology, and literature review. 

Automation - Device or system that accomplishes (partially or fiilly) a function that was 
previously, or conceivably could be, carried out (partially or fully) by a human operator 
(Parasuraman et al., 2000). 
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Key Performance Parameter (KPP) - KPPs are those attributes or eharaeteristics of a 
system that are eonsidered eritieal or essential to the development of an effective military 
capability. 

Human Systems Integration (HSD - comprehensive management and technical program 
that focuses on the integration of human considerations into the systems acquisition 
process. 

MANPRINT - acronym for Manpower and Personnel Integration, the US Army’s 
implementation of HSI that focuses on the integration of human considerations into the 
system acquisition process to enhance soldier-system design, reduce life cycle ownership 
costs, and optimize total system performance. 
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II. REVIEW OF THE RELEVANT LITERATURE 


A. UNIT OF ACTION (UA), UNIT OF EMPLOYMENT (UE), AND FUTURE 

COMBAT SYSTEMS (FCS) 

1. UA/UE Doctrine and the ‘Quality of Firsts’ 

Prior to beginning a rigorous systems engineering and capabilities needs process 
that will produce FCS, it is imperative to thoroughly understand the fighting doctrine that 
the Amy envisions for the Year 2015 and beyond. The Army’s Training and Doctrine 
Command (TRADOC) argues that an increasingly demanding operational environment 
(OE) points to the necessity to build a “ground force designed for rapid deployment and 
operations across the full spectrum of war” (US Army TRADOC, 2003). 

To do this, TRADOC envisions two major echelons of combat formations: the 
Unit of Action (UA), and the Unit of Employment (UE). UEs will be tailorable, higher- 
level echelons (what we now know as division, corps, and echelons above corps) that 
integrate and synchronize Army, Joint, and Multinational forces for full spectrum 
operations at higher operational levels of war. They link ground and joint forces and 
orchestrate ground operations that decide joint campaigns. UEs will focus on major 
operations and decisive land campaigns in support of joint operational and strategic 
objectives. 

Units of Action (UA) will be the tactical warfighting echelons of the Army’s 
Future Force (analogous to what we now call brigade and below). One or more UAs may 
fight under the command and control of a UE. The UA will fight battles; the UE will 
orchestrate multiple engagements to win battles. The function of the UA is to close with 
and destroy enemy forces though integrated fire and maneuver, and tactical assault. UAs 
will initiate operations to gain information superiority and fully understand the terrain, 
weather, enemy, and friendly forces; then turn that knowledge to advantage (US Army 
TRADOC, 2002). 

There are two key concepts in this brief discussion of the UA that are pertinent. 
First, formations in the UA will be enabled be a ‘Quality of Firsts’—See First, 
Understand First, Act First, and Finish Decisively. UA capabilities will permit future 
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commanders to “develop the situation before making contact, maneuver to positions of 
advantage and, when ready, initiate decisive action by destroying enemy systems beyond 
the range of their weapons to set the conditions for decisive assault and the UA’s ability 
to develop situations out of contact” (US Army TRADOC, 2003, p. 1-2). The second key 
concept, already alluded to, is that UAs must develop the situation out of contact, without 
the need to first find and fix the engaged enemy force (US Army TRADOC, 2002). This 
is a leap-ahead operational paradigm, to be enabled by new and emerging technologies. 
In the past, ground maneuver units conducted ‘maneuver to contact’ in order to find and 
fix the enemy, putting the formation at significant risk. The UA concept directs that 
Army forces will find and understand the enemy prior to establishing contact, and then 
act before the enemy has a chance to put the formation in harm’s way. 

How does this UA/UE doctrine pertain to PCS? Simply put PCS is the materiel 
solution to meet the UA/UE concept of future warfare, or how the Army wants its 
soldiers and units to fight in the future. To understand the materiel requirements, it is 
vital to thoroughly understand the fighting doctrine that PCS is being built to achieve. 
PCS is conceived to enable the networked UA to “develop the situation in and out of 
contact, set conditions, maneuver to positions of advantage, and to close with and destroy 
the enemy through standoff attack and combat assauh” (US Army TRADOC, 2003, p. 
1-3). As described in Chapter I, the PCS Pamily of Systems (PoS) includes a planned 
fleet of manned ground vehicles that will provide specific functions in support of the 
operational concept. “The manned systems will provide capabilities that will enable many 
of the key operational parameters of the PCS force, including lethality overmatch, 
assured survivability and battle command on the move. Essentially, these [marmed] 
systems contribute to the synergy that facilitates the ‘quality of firsts’” (US Army 
UAMBL, 2005, p. D-1). 

2. PCS ORD 

To understand the capabilities and requirements that the US Army and the LSI are 
trying to develop with PCS, especially as it pertains to various automation designs in the 
MGV fleet, it is necessary to thoroughly review the PCS ORD. The ORD places many 
requirements and needed capabilities on the MGV fleet and associated network, far too 
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many to review in this thesis. There is an implicit assumption in the PCS program is 
expecting the development and maturation of a number of advanced automation 
technologies that can be integrated in the overall FoS and the MGV fleet. 

The FCS ORD (see US Army UAMBL, 2005, A nn ex D) calls for eight manned 
platforms that provide specific functions in support of the operational concept: Mounted 
combat system (MCS), Infantry carrier vehicle (ICV), Non-line-of-sight cannon (NLOS- 
C), Non-line-of-sight mortar (NLOS-M), Reconnaissance and surveillance vehicle 
(RSV), Command and control vehicle (C2V), Medical vehicle (treatment and evacuation 
variants; MV-E and MV-T), and the FCS Recovery and Maintenance Vehicle (FRMV). 
Figure 3 outlines the fleet in development. The approach is to maximize commonality of 
these platforms, to include a co mm on crew station (CCS) among all eight vehicles. Also 
of particular importance to this thesis is the requirement that the manned systems must be 
operable by a 2-man crew (a driver and vehicle commander). The current lone exception 
is the MCS variant which has been approved for an increase to a 3-soldier crew. 
IMPRINT analysis by Mitchell, Samms, Henthom, and & Wojciechowski (2003) was the 
primary driver of this increase. 



Figure 3. FCS Manned Ground Vehicle (MGV) Fleet 
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To gain an appreciation for the breadth and width of the requirements placed on 
the MGV fleet, and the implicit demands for highly advanced automation that must 
follow, here is a list of four major requirements placed on the common crew station: 

• Wireless, remote operation of the vehicle by a dismounted crewman 

• Control of unmanned systems and their payloads/mission packages 
(including unmanned aerial vehicles and unmanned ground systems) 

• Control other manned platforms through robotic, non-mechanical tether 
(up to six vehicles) 

• Operable by one crewmember for limited periods of time 

Each one of these ORD requirements would require a major systems engineering and 
R&D effort to achieve the desired automation design. Undoubtedly, the V.I. team will 
assign knowledgeable, dependable, multidisciplinary teams of engineers and scientists to 
work on each requirement. However, it is safe to say that each team will take a 
significantly different approach to achieving their goal. The result will be four totally 
different schemes to describe the resulting interaction between the human crew and the 
hardware/software automation design. Thus, the burden will be placed on the operators, 
as well as the training system, to gain a full understanding of how each of these modes 
will operate. 

Beyond the four examples of automation modes highlighted above, there are 
dozens of calls for advanced automation design on the MGV fleet throughout the ORD, 
both explicit and implicit. Several examples are: embedded sensor suites, physiological 
monitoring, weapons engagements, cooperative engagements, chemical-biological hazard 
detection, signature management, laser detection, automatic internal lighting, air self 
defense against multiple aerial targets, automated mission planning, acquisition and 
prioritization of multiple targets, monitoring and analysis of multiple supply needs, 
embedded prognostics and diagnostics for maintenance, automated preventative 
maintenance checks, decision aids to facilitate maintenance planning, and the list goes 
on. As an extension of the argument in the previous paragraph, the V.I. team will employ 
dozens of dedicated engineers and scientists in a strenuous attempt to meet these 
requirements. However, each person or team will likely work independently of each other 

and develop their own overarching architecture for their piece of automation. Some may 
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attempt to explicitly design the interaction between human and automation, but many will 
not. The results will be dozens of different schemes, explicit or implicit, to describe the 
resulting interaction between the human crew and the hardware/software automation 
design. Ultimately, it will be up to the PCS training system and the Soldier to learn and 
understand the many different modes of operation. This may well make it more difficult 
for soldiers to achieve acceptable operations or maintenance performance in the vehicle 
system (though we have yet to empirically prove this). 


B. HISTORICAL EXAMPLES OF AUTOMATION VS. MANNING LEVELS 

The Army’s PCS is by no means the first attempt to make the tradeoff between 
advanced automation design and the promise of reduced manning levels in extremely 
complex systems. There are four historical examples reviewed in an attempt to acquaint 
the reader with other major technology systems that were heavily concerned with the use 
of automation and the resulting manpower and human performance concerns, both in and 
out of the US DoD. They include a European nuclear power plant, a NASA project, the 
US Navy’s DD-X, and ending with the Army’s LHX program. 

1. Nuclear Power Plant - Balancing Automation and Human Action 

In a case study of a specific nuclear power plant in Europe, Pewins, Mitchell, and 
Williams (1992) reviewed the assessment of the plant’s operation to ascertain whether 
proposed staffing levels were adequate. The primary objective was to assess “whether 
automation provisions with the design system would enable a specified plant manoeuvrre 
to be adequately carried out given the minimum main control room (MCR) staffing 
complement of one supervisor and one desk operator” (Pewins et al., 1992, p. 241). 
Additional objectives included identifying requirements for man-machine interface, work 
organization, training, and procedures; HSl/MANPRINT practitioners will recognize the 
similarity to the domains of human factors engineering, manpower, personnel, and 
training. They conducted a hierarchical task analysis, timeline analysis, and workload 
assessment to meet their objectives. 

Their analysis strongly indicated that the workload assessed was within the 
capability of an increased staff of two desk operators and a supervisor, provided that 
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limited developments to the automation were adopted. However, the workload was much 
too high for the minimum staffing complement (one operator and one supervisor) without 
widespread automation, which was not considered practicable because of safety 
implications and projected cost. They reco mm ended an additional desk operator in the 
staffing complement. Fewins, et al. (1992) also concluded that limited automation was 
an acceptable option for reducing operator workload in selected functions and tasks. The 
use of their methodology provided useful recommendations for the automation of parts of 
the control process, as well as man-machine interface design, and procedures and 
training. 

2. Advanced Automation in Spaceflight Systems 

Despite its acknowledged potential, advanced automation is rarely used in 
spaceflight systems, because many managers consider intelligent control systems an 
unacceptable risk. A group of NASA researchers make the case for introducing more 
advanced automation into spaceflight systems by defining systems engineering practices 
that improve reliability and earn trust (Freed, Bonasso, Ingham, Kortenkamp, Pell, & 
Penix, 2005). They argue that automation reduces dependences on people in potentially 
advantageous ways that can pay off as reduced staffing and training costs. In addition, 
onboard automation “can perform actions that would otherwise be performed by the 
crew” (Freed et ah, 2005), enable reduced crew size requirements among other potential 
benefits. 

Freed et al.’s vision of advanced automation allows goal-based commanding of 
system activities, in contrast to timed action-sequence commanding traditionally used. 
They also argue for variable autonomy, or the ability of intelligent control software to 
supports changes in degree of automation. The goal of variable autonomy software 
architecture is to allow systems to operate with dynamically varying levels of 
independence, intelligence and control. “A human user, another system, or the 
autonomous user itself may adjust the system’s ‘level of autonomy’ as required by the 
current situation” (2005, p. 6). A key conclusion from their arguments is that variable 
autonomy is necessary for any application of autonomous control technology that needs 
to interact with humans [emphasis added]. “Humans who rely on the autonomous control 
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systems will want to be able to take control of it at various times and at various levels” 
(2005, p. 8). Their concepts on variable autonomy play a key part in the model of 
human-automation interaction proposed in this thesis. 

3. US Navy’s Manning Affordability Initiative and the DD-X 

Engineers and scientists with the US Navy conducted a program in 1995-2000 
called the Manning Affordability Initiative (MAI) which aimed to provide the 
“processes, tools, interaction guidelines, and procedures required to optimize a combat 
systems environment for the warfighter at reduced manning levels” (US Navy, 2002). 
The goal of the program was at least a 50% manpower reduction while demonstrating 
operational utility for all functions and maintaining or improving a ship’s operational 
performance. 

In a series of papers advocating an HSI approach to achieving reduced manning 
levels on future US Navy ships, there emerged three main themes to achieve reduced 
manning. First, move many functions currently performed by the ship’s crew off the ship. 
Second, accept increased levels of risk by eliminating or consolidating some watch 
stations and reducing some support and hotel services. Finally, the point to the need to 
invest in emerging technologies that would reduced the number of sailors need onboard 
navy ships (Bost & Galdorisi, 2004; see also Malone & Bost, 2000; Hamburger, Bost, & 
McKneely, 1999). 

The group went on to argue for the selective insertion of technology (i.e., 
automation) to enhance operator performance or substitute for manpower, with “human 
supervision of automated processes and human selection of automation levels. With the 
advent of ‘smarter’ systems that work cooperatively with human supervision, the role of 
many warfighter shifts from manual control and data input towards strategic thinking and 
planning. This shift in design focus may allow one operator to supervise processes and 
systems that were previously controlled by two, three, or more operators. Thus, 
automation must be planned carefully and designers must not necessarily take the human 
out of the information loop just because the control loop is removed in a mission 
process.” (Bost & Galdorisi, 2004, p. 8). 
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Another key aspect from the Navy’s MAI is the explicit call for a top-down 
function analysis (TDFA) and top-down requirements analysis (TDRA). Bost, 
McKneely, and Hamburger (1998) call the TDFA a process that evaluates which tasks 
should be down manually and which should be done with automation. Typically, the 
human element is not considered in the TDFA, leading to systems that do not account for 
human capabilities or limitations. They argue for tools such as better allocation of 
functions, function decomposition, and workload assessment, to name a few. Similarly, a 
TDRA is concerned with identifying, analyzing, and integrating requirements for 
missions, system functions, and human involvement in the performance of functions. In 
addressing approaches to reduce system manning, “simply automating system functions 
will not provide the warfighter with what he or she needs to monitor, plan, react, 
understand, maintain situation awareness, supervise, make decisions, make judgments, 
and modify plans due to changes in the tactical situation’’ (Malone & Bost, 2000, p. 1). 
The go on to argue for the TDRA as the HSI process for defining human requirements 
early in system development. “The only viable approach to optimal manning reduction is 
to develop a system where human and machine synergistically and interactively 
cooperate to conduct the mission, and where the automated systems supports human 
performance....’’ (2000, p. 1). 

Before we close with our review of the Navy’s MAI and reduced-manning 
programs, it is important to draw attention to the Navy’s DD(X) program, a family of 
Navy ships with a peculiar and unique requirement: they must be manned by a mere 95 
sailors, one-third the usual size of current or previous ships in a similar mission class. In 
fact, the manning requirement is a Key Performance Parameter (KPP) on the DD(X) 
program, a huge boon the HSI practitioners involved with the program and the MAI. 
Since manning is a KPP on the DD(X) program, it will gain serious attention, engineering 
effort, resources, and manpower since the DD(X) program manager and the Navy must 
prove that the DD(X) can perform to published standards with a severely reduced crew 
complement. This fact is important to note because the 2-soldier crew requirement on the 
Army’s FCS MGV fleet is not a KPP, and so far has not gained a comparative attention 
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and engineering effort to prove that its vehieles can be operated by only 2 soldiers (as 
compared to the traditional 4 soldiers or more). 

4. The US Army’s LHX Program 

The reduced manning goals in PCS’ MGV fleet are by no means the Army’s first 
attempt to realize manpower savings via the promise of advanced automation. Perhaps 
the most ambitious helicopter development program ever undertaken by the US Army 
was the LHX (for Light Helicopter, Experimental), a system that eventually became the 
RAH-66 Comanche. The Army originally conceived the LHX as a 7500-lb aircraft 
requiring only a single crewmember, an advantage that would result in a smaller target 
profile, as well as realize considerable manpower savings over the life-cycle of the 
system. Of course, design for single crewmember operations would require considerable 
effort and expense to automate many systems operations and functions. Army 
helicopters with similar missions have always employed two crewmembers, a pilot and 
gunner/observer (both rated aviators). In effect, the Army’s goal was to introduce such 
advanced automation as to replace a human operator and reduce crew size by 50%. 

Rigorous analyses by the Army Research Institute Field Units at Fort Rucker, 
Alabama (home of the US Army Aviation Center) looked into human performance data 
while evaluating various automation options, as well assessing the feasibility of operating 
the LHX with a single crewmember. In a landmark publication, McCracken & Aldrich 
(1984) developed an analytical process for evaluating human task-loading in the LHX 
under 29 different mission scenarios, effectively predicting mental workload via 
computational analysis. In fact, the analytical process developed by McCracken and 
Aldrich is a precursor of today’s IMPRINT software. The results of their study concluded 
that the human in a single-pilot aircraft would become overwhelmed in critical situations 
(i.e. weapons engagements), even with considerable theorized automation help. Further 
analysis predicted that a dual-crewmember aircraft would experience multiple overload 
conditions in 22 of 29 mission segments, thus requiring some automation even with two 
operators in the cockpit. 

In addition to the analysis at Fort Rucker, the Army established the Crew Station 
Research and Development Facility (CSRDF) at NASA’s Ames Research Center at 
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Moffett Field in Mountain View, CA with the express purpose of evaluating technologies 
and human performance to determine whether single-pilot operations were feasible in the 
LHX. Despite considerable efforts at Fort Rucker, the US Army Aviation Systems 
Command in St. Louis, Missouri, and the CSRDF at NAS A-Ames, by late 1987 the data 
available on LHX crew performance was pointing towards the need for a dual¬ 
crewmember setup. Accordingly, the LHX Program Manager went the US DoD 
Acquisition Executive and recommended a flat decision to continue development with a 
two-crewmember crew station that was single-pilot operable (personal communications. 
Dr. Michael McCauley, July 2005; James Minninger, October 2005; Dr. Harold Booher, 
October 2005; see also Booher, 1997). 

5. The US Army’s Previous Crew Reduction Efforts for Ground 
Vehicles 

Before the thesis closes the review on previous examples of manning vs. 
automation, it is correct to note that the Army has been looking at reduced manning in its 
ground vehicles for some time. The US DoD Human Factors Engineering Technical 
Advisory Group (HFETAG) has been looking at reduced manning for ground vehicles 
since at least the mid-1980s. A review of the meeting minutes from the HFETAG 
website (http://hfetag.dtic.milj shows that several of the HFETAG meetings in the past 
twenty years had presentations on crew size reduction in armored vehicles. 

An extension of the 1980s HFETAG crew reduction efforts is the Crewman’s 
Associate Advanced Technology Demonstration (CA-ATD) sponsored by the US Army’s 
Tank-Automative Command (TACOM). Active during 1994-2003, the CA-ATD 
focused on the integration of the crew and electronic subsystems into current and future 
vehicles, accomplished through the development of advanced crew stations which would 
increase crew performance and reduce crew workload. The CA-ATD program also 
focused on ways to create a two-man crew station while maintaining combat 
effectiveness. Many of the products and results of the program are being incorporated 
into the MGV fleet designs (personal communications. Dr. Patty Lakinsmith, July 2005; 
see also Karjala, 2001). 
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Lastly, the LFS Army nearly fielded a tank-like vehiele with a three-man erew 
(versus the standard four-man) in the mid-1990s. The M8 Armored Guns System (AGS) 
was designed to be an air-droppable, lightweight gun system, but only required a crew of 
three through the use of an autoloader (a mostly physical, vice cognitive, function 
previously performed by the fourth crewmember). However, the program was terminated 
in 1996 and abandoned, ostensibly due to budget issues. Incidentally, the AGS is an 
example of a program in which MANPRINT considerations were purposely rejected; it is 
not a coincidence that the Army canceled the program (see Booher, 2003, p. 667; 
Federation of American Scientists, 2000). 


C. FUNCTION ALLOCATION 

At the heart of these previous examples of automation design versus possible 
manpower reduction has been the concept of function allocation (FA). Its main aim is to 
provide a rational means of determining which systems-level functions should be carried 
out by humans and which by machines. As technology has progressed over the past 
several decades, many purchasers of advanced (and expensive) defense weapons systems 
have made the not-unreasonable assertion that advanced technology can take over many 
tasks and functions previously done by human beings—^the most variable, unpredictable, 
and expensive part of the overall system. “Function allocation tries to balance attempts to 
mechanize or automate as many system functions as possible by seeking roles and tasks 
for humans that makes the best use of their capabilities while recognizing human 
limitations” (Beevis, Essens, & Schuffel, 1996, p. 1). Function allocation is linked to 
issues of automation and manpower reduction, as well as to questions about human 
responsibility for the safe and effective operation of a system. 

In 1951, Dr. Paul Fitts edited and prepared a report titled ifwwan Engineering for 
an Effective Air-Navigation and Traffic Control System. In this report he created two 
lists, one defining what man is better able to accomplish, and another listing what 
machines are better able to accomplish. This seminal contribution to the literature 
effectively started the discipline known as Function Allocation. By the late 1950s, the 
Fitts’ List approach of comparing human and machine capabilities had been incorporated 
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into a number of human engineering guidelines (Beevis, Essens, & Sehuffel, 1996). This 
approaeh grew into what became known as the MABA-MABA (Men are Better At— 
Machines are Better At) lists. This general approach was the primary way to determine 
function allocation within a system. Table 1 lists the relative capabilities originally 
developed by Fitts and adapted from Sheridan (2002) and Fuld (2000) (as cited in 
Wickens, 1992, p. 429). 


Table 2. _ "Fitts' List" Showing the Relative Benefits of Automation and Humans 


Humans are better at 

Automation is better at 

Detecting small amounts of visual, auditory, or 
chemical signals (e.g., evaluating wine or 
perfume) 

Monitoring processes (e.g., warnings) 

Detecting a wide array of stimuli (e.g., integrating 
visual, auditory, and olfactory cues in 
cooking) 

Detecting signals beyond human capability (e.g., 
measuring high temperatures, sensing infrared 
light and x-rays) 

Perceiving patterns and making generalizations 
(e.g., “seeing the big picture”) 

Ignoring extraneous factors (e.g., a calculator 
doesn’t get nervous during an exam) 

Detecting signals in high levels of background 
noise (e.g., detecting a ship on a cluttered 
radar display) 

Responding quickly and applying great force 
smoothly and precisely (e.g., autopilots, 
automatic torque application) 

Improvising and using flexible procedures (e.g., 
engineering problem solving, such as on the 
Apollo 13 moon mission) 

Repeating the same procedure in precisely the 
same manner many times (e.g., robots on 
assembly lines) 

Storing information for long periods and recalling 
appropriate parts (e.g., recognizing a friend 
after many years) 

Storing large amounts of information briefly and 
erasing it completely (e.g., updating predictions 
in a dynamic environment) 

Reasoning inductively (e.g., extracting meaningful 
relationships from data) 

Reasoning deductively (e.g., analyzing probable 
causes from fault trees) 

Exercising judgment (e.g., choosing between a job 
and graduate school) 

Performing many complex operations at once (e.g., 
data integration for complex displays, such as 
in vessel tracking) 


Despite the marvelous simplicity of the Fitts List, most practitioners and 


researchers seem wholly unsatisfied with the progress of the FA discipline as a whole 
over the past five decades. This general guideline to FA was, at the time, a proactive 
approach to embedding concerns for human capabilities and limitations in systems and 
provided a sense of direction for the discipline. However, this historical approach and its 
practice in the ensuing decades came to be an unrealistic and outdated concept, never 
fully developing into a useful concept. A 1992 NATO research group called FA the 
weakest in a group of six human engineering analysis techniques (Beevis, Essens, & 
Sehuffel, 1996), and the International Journal of Human-Computer Studies dedicated its 


24 



entire February 2000 special issue to review the status of FA. The workshop drew the 
following conclusions [Beevis et al., 1996, p. xix]: 


• Problems with terminology remain, particularly when human factors 
specialists communicate with those in other engineering disciplines 

• FA is not an isolated activity and must be incorporated in the development 
process early enough to influence design decisions and to permit iteration 

• No single technique is available that deals with all of the issues involved 
in assigning functions 

• FA decisions must be validated by predictions of operator workload or 
system performance and the allocation decisions revised if necessary in an 
iterative approach 

• Little research activity is devoted currently to human behavior in systems 
operations or to improving human factors engineering techniques 

Perhaps the most telling quote comes from Sheridan, concluding that FA practitioners are 
“obliged to continue our efforts to underpin what is essentially an artful design synthesis 
with a modicum of science (2000, p. 204). 


D. AUTOMATION DESIGN IS NOT AN ‘ALL-OR-NONE’ CONCEPT - 

LEVELS OE AUTOMATION 

I. Levels (Degrees) of Automation 

While the Fitts list gives a useful starting point to think about the allocation of 
functions between human and automation (hardware and/or software), many layman tend 
to see the allocation as an ‘all-or-none’, black-or-white, binary affair. The function or 
task is either completely manual or completely automatic, with nothing in between. We 
can point to robotized factories as a popular example in the media, with little mention of 
the associated programming, monitoring, fault detection and diagnosis, and maintenance 
functions performed by humans (Sheridan, 1992, 2002). The truth, at the heart of this 
thesis, is that humans and automation will work together as part of the FCS Family of 
Systems. “The human and computer can interact in an infinite number of ways, resultant 
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in an infinite spectrum of allocation possibilities from which to choose” (Sheridan, 2002, 
p. 58). 


Automation can vary across a “continuum of levels, from the lowest level of frilly 
manual performance to the highest level of full automation” (Parasuraman, Sheridan, & 
Wickens, 2000, p. 287). Table 3 shows the 10-point scale with higher levels 
representing increased autonomy of the machine over the human. For example, at a low 
level 2, several options are provided to the human, but the system has no further say in 
which decision is chosen. At level 6, the system automation gives the human only a 
limited time to override before carrying out the decision. Each level carries with it 
additional opportunities for machine error; each precludes human intervention to a 
greater extent. 

Along with the scale that he largely developed, Sheridan (1992) anticipated that 
for some tasks, we are happy to let the computer go all the way, while for others we 
would prefer to limit automation at a level well down in the list. The tendency has been 
to automate what is easiest and to leave the rest to the human. “From one perspective, this 
dignifies the human contribution; from another it may lead to a hodgepodge of partial 
automation, making the remaining human tasks less coherent and more complex than 
they need be and resulting in an overall degradation of system performance” (Sheridan, 
1992, p. 358). 

Table 3. Levels of Automation of Decision and Action Selection (Parasuraman, 


Sheridan, and Wickens, 2000). 


High 

10. The computer decides everything and acts autonomously, ignoring 
the human 


9. Informs him or her after execution if it, the computer, decides to 


8. Informs him or her after execution only if he or she asks, or 


7. Executes automatically 


6. Allows the human a restricted time to veto before automatic 
execution, or 


5. Executes that suggestion if the human approves, or 


4. Suggests one, and 


3. Narrows the selection down to a few, or 


2. The computer offers a complete set of action alternatives, or 

Low 

1. The computer offers no assistance; the human must do it all 
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2. A Model for Types and Levels of Automation 

Along with this ‘Levels-of-Automation’ (LOA) approach, Parasuraman, Sheridan, 
and Wickens (2000) extended the concept to cover automation of different types of 
function in a human-machine system. The scale in Table 3 refers mainly to “automation 
of decision and action selection, or output functions of a system. However, automation 
may also be applied to input functions, i.e. to functions that precede decision making and 
action” (2000, p. 287). Thus, in expansion of the LOA concept, they proposed a four- 
stage view of human information processing (Figure 4). 



Figure 4. Simple four-stage model of human information processing (Parasuraman, 

et al., 2000) 


By their own admission, this four-stage model is almost certainly a “gross 
oversimplification of the many components of human information processing” (2000). 
However, their structure is useful in practice, and provides a “simple starting point with 
surprisingly far-reaching implications” for designing the interaction scheme between a 
human and automation. They go on to reason that the four-stage information processing 
model of has “its equivalent in systems functions that can be automated” (2000). They 
further proposed that automation can be applied to four classes of function (see also 
Sheridan, 1998; Billings, 1997; Lee & Sandquist, 1996): 

1. information acquisition 

2. information analysis 

3. decision and action selection 

4. action implementation 

Each of these functions can be automated to differing degrees, or many levels. 
The multiple levels of automation of decision making (as shown in Table 2) “can be 
applied, with some modification, to the information acquisition, information analysis, and 
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action implementation stages as well” (Parasuraman, et al., 2000, p. 288). Students and 
fans of the late Colonel John Boyd, US Air Force, may appreeiate how the four broad 
funetions of this model are analogous to the infamous Observe-Orient-Deeide-Aet 
(OODA) loop eommonly used by defense and business personnel around the world (see 
Boyd, 1996). 

The particular advantage of the Parasuraman, Sheridan, and Wickens model is the 
simple sehematie they provide for model types and levels of automation (Figure 5). A 
partieular system ean involve all four dimensions at different levels. Thus, for example, a 
given system (A) could be designed to have moderate to high aequisition automation, low 
analysis automation, low deeision automation, and low action automation. Another 
system (B), on the other hand, might have high levels of automation across all four 
functions (2000). Their graphical representation of a human-automation interfaee 
seheme makes it particularly easy to envision the overarehing funetional architeeture of a 
system, to see exaetly how a human will internet with the designed automation. Like 
slider bars on your stereo equalizer, systems and human faetors engineers ean ‘slide up’ 
or ‘slide down’ the level of automation in each major function of a particular, thereby 
explicitly specifying how the human will interact with the automation. 
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acquisition, information analysis, decision selection, and actin implementation. 
Examples of two systems with different levels of automation across functional 
dimension are also shown (Parasuraman et al, 2000). 


The model they outlined provides a “framework for examining automation design 
issues for specific systems” (2000, p. 289). They proposed a series of steps and an 
iterative procedure for examining which system functions should be automated and to 
what extent. They go on to argue that the human performance consequences of specific 
types and levels of automation constitute the “primary and secondary evaluative criteria 
for automation design using the model” (2000, p. 286). Their primary evaluative criteria 
include mental workload, situation awareness, complacency, and skill degradation. 
Secondary evaluative criteria include automation reliability and costs of decision/action 
outcomes. All of these should be applied “to evaluate the feasibility and appropriateness 
of particular levels of automation” (2000, p. 289) in an iterative process. 
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In a closely related paper published at the same time, Parasuraman (2000) also 
discusses the types-and-levels model as a qualitative approach to human-automation 
interaction design. However, he also goes on to argue for the development of 
quantitative models that eould inform the design of human-automation interaction, 
pointing out several computational and formal models of human interaction with 
automation. For example, if available, sueh models “eould address the major issue in the 
design of effeetive human-automation interaction, namely the determination of the 
speeifie type and level of automation in a particular system....There may be tradeoffs in 
benefits and costs involved in different levels of automation and ehoosing the level that 
maximizes the overall gain may be guided by quantitative models” (2000, p. 940). He 
concludes that “an important future research need is the integration of qualitative and 
quantitative models” (2000, p. 946) which should provide for a more objective basis for a 
determining effective modes of human interaction with automation. 

Overall, the model presented in Parasuraman et al. (2000) and Parasuraman 
(2000) is the foundation for this thesis, as will be illustrated in Chapter III. Starting with 
their model for types and levels of automation, the proposed qualitative model blends 
ideas from three other research teams, each of which is discussed below. Beyond that, 
the urging from Parasuraman (2000) to blend in a quantitative approach gives rise to the 
use of IMPRINT from ARL/HRED as a way to predict operator task-loading once the 
proposed qualitative model is applied to a system in development. 


E. OTHER LEVELS-OF-AUTOMATION RESEARCH 

1. Kaber & Endsley Using a Dynamic Control Task 

In addition to the four-stage model proposed by Parasuraman, Sheridan, and 
Wickens, there are two other major research teams that have proposed level-of- 
automation taxonomies similar in seope and intent. The first major thrust comes from 
Endsley and Kaber (1999; see also Endsley & Kaber, 2004; Kaber, Endsley, Wright, & 
Warren, 2002). These researchers developed a 10-level taxonomy applicable to a wide 
range of psychomotor and cognitive tasks, as well as numerous work domains, with four 
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generic functions that can be allocated to a human operator and/or a computer. The 
functions are: 


1. Monitoring: taking in all information relevant to perceive system status 

2. Generating: formulating options or task strategies for achieving goals 

3. Selecting: deciding on a particular option or strategy 

4. Implementing: carrying out the chosen option through control actions at an 
interface 

In their work, ten LOAs were systematically formulated by assigning these four functions 
to the human or computer, or a combination of the two, as shown in Table 3. 


Table 4. LOA Taxonomy for human-computer performance in dynamic, multitask 


scenarios (Endsley & Kaber, 1999; Kaber & Endsley, 2004) 


Level of Automation 

Functions 

Monitoring 

Generating 

Selecting 

Implementing 

(1) Manual Control 

Human 

Human 

Human 

Human 

(2) Action Support 

Human/Computer 

Human 

Human 

Human/Computer 

(3) Batch Processing 

Human/Computer 

Human 

Human 

Computer 

(4) Shared Control 

Human/Computer 

Human/Computer 

Human 

Human/Computer 

(5) Decision Support 

Human/Computer 

Human/Computer 

Human 

Computer 

(6) Blended Decision Making 

Human/Computer 

Human/Computer 

Human/Computer 

Computer 

(7) Rigid System 

Human/Computer 

Computer 

Human 

Computer 

(8) Automated Decision Making 

Human/Computer 

Human/Computer 

Computer 

Computer 

(9) Supervisory Control 

Human/Computer 

Computer 

Computer 

Computer 

(10) Full Automation 

Computer 

Computer 

Computer 

Computer 


Kaber and Endsley (2004, p. 115) contend that their LOA taxonomy provides 
several advantages over previous/historical hierarchies of LOAs. It provides greater 
detail on ‘who’ (the human or computer) is doing ‘what’ at each LOA.” Furthermore, the 
list (Table 3) does not ‘‘focus only on decision making and defining authority.” The key 
advantage is that it allows ‘‘careful empirical assessment of which aspects of automation 
might be helpful or harmful to human performance in conjunction with [the proposed] 
system.” They cite the Parasuraman et al. (2000) model for LOA design, but point out 
that their own model considers the option generation (planning) function, instead of the 
information analysis function in the Parasuraman et al. model. However, the other three 
functions in the Parasuraman et al. model are identical to the monitoring, selection, and 
implementation features of the Kaber & Endsley taxonomy (see Table 4). 
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Table 5. Comparison of Taxonomies: Parasuraman, Sheridan, & Wickens vs. 


Kaber & Endsley 


Parasuraman, Sheridan, & Wickens 
(2000) 


Kaber & Endsley (2004); Endsley & 
Kaber (1999) 

Information Acauisition 

= 

Monitorins 

Information Analvsis 

— 

1 _ ■ 


— 

Generating 

Decision Selection 


Selecting 

Action Imnlementation 

= 

Imnlementing 


In the three publieations eited from the team of Kaber and Endsley, they drew a 
number of eonclusions regarding automation design and EGAs. In Endsley and Kaber 
(1999), their researeh explored various EGAs in the eontext of a dynamic control task as 
a means of improving overall human/machine performance. Results suggest that, in terms 
of performance, “human operators benefit most from the implementation portion of the 
task, buy only under normal operating conditions” (1999, p. 462). In addition, joint 
human/automation option generation significantly degraded performance in comparison 
to human or automated option generation alone. 

A follow on study from Kaber and Endsley (2004) examined the effects of EGAs 
in interaction with adaptive automation in a similar dynamic control task. Again, results 
revealed EGA to be the driving factors in determining primary task performance. “The 
results are supportive of intermediate EG As... as approaches to human-centered 
automation” (2004, p. 113). The empirical results from these studies, combined with 
other EGA empirical research (such as Ruff et al., 2002, below), give us some guidelines 
for choosing EGAs in new human-automation systems under development. The results 
give us an initial target for the proper EGA and at the proper function to gain improved 
human performance in the human-automation interaction. 

2. LOA Taxonomy from NASA 

The other major EGA taxonomy in the literature is a four-stage model from 
Proud, Hart, and Mrozinski (2003) out of the National Aviation and Space 
Administration’s (NASA) Johnson Space Center in Houston, TX. These engineers were 
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seeking to shift, where appropriate, several functions from humans to an autonomous 
flight management (AFM) system, encapsulated in a prototype call SMART (Spacecraft 
Mission Assessment and Re-planning Tool). SMART is a “functionally decomposed 
flight management system with an appropriate level of autonomy for each of its 
functions” (2003, p. 1), but Proud et al. needed a method to determine the appropriate 
level of autonomy for each function within a system. Starting with Sheridan’s degrees of 
automation scale (1992; see Table 2) and then moving to the Parasuraman et al. (2000) 
four-stage model already discussed, they realized that the AFM functions fell into a 
similar four-tier system using the terms monitor, analyze, decide, and act. 

They correctly realized one of the limitations of the LOA scale (Table 2) in that 
Sheridan’s lO-LOA scale refers mainly to automation of decision and action selection, or 
the output functions of a system. Automation may also be applied to the input functions 
of system, i.e. the information acquisition, information analysis, and even option 
generation functions. They then integrated aspects of Boyd’s OODA loop (Boyd, 1996) 
to develop an 8-level level of autonomy scale to determine how to assign a level of 
autonomy for a particular function (Figure 6). 


Level 

Observe 

Orient 

Decide 


8 

The computer gathers, 
filters, and prioritizes 
data without displaying 
any information to the 
human. 

The computer predicts, 
interprets, and integrates 
data into a result which is 
not displayed to the 
human. 

The computer performs 
ranking tasks. The 
computer erforms final 
ranking, but does not 
display results to the 
human. 

Computer executes 
automatically and does 
not allow any human 
interaction. 

7 

The computer gathers, 
filters, and prioritizes 
data without displaying 
any information to the 
human. Though, a 
program functioning" 
flag is displayed. 

The computer analyzes, 
predicts, interprets, and 
integrates data into a 
result which is only 
displayed to the human if 
result fits programmed 
context (context 
dependant summaries). 

The computer performs 
ranking tasks. The 
computer performs final 
ranking and displays a 
reduced set of ranked 
options without 
displaying "why" 
decisions were made to 
the human. 

Computer executes 
automatically and only 
informs the human if 
required by context. It 
allows for override 
ability after execution. 
Human is shadow for 
contingencies. 
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Level 

Observe 

Orient 

Decide 


6 

The computer gathers, 
filters, and prioritizes 
information displayed to 
the human. 

The computer overlays 
predictions with analysis 
and interprets the data. 
The human is shown all 
results. 

The computer performs 
ranking tasks and 
displays a reduced set of 
ranked options while 
displaying “why” 
decisions were made to 
the human. 

Computer executes 
automatically, informs 
the human, and allows 
for override ability after 
execution. Human is 
shadow for 
contingencies. 

5 

The computer is 
responsible for gathering 
the information for the 
human, but it only 
displays nonprioritized, 
filtered information. 

The computer overlays 
predictions with analysis 
and interprets the data. 
The human shadows the 
interpretation for 
contingencies. 

The computer performs 
ranking tasks. All results, 
including "why" 
decisions were made, are 
displayed to the human. 

Computer allows the 
human a context- 
dependant restricted time 
to veto before execution. 
Human shadows for 
contingencies. 

4 

The computer is 
responsible for gathering 
the information for the 
human and for 
displaying all 
information, but it 
highlights the non¬ 
prioritized, relevant 
information for the user. 

The computer analyzes 
the data and makes 
predictions, though the 
human is responsible for 
interpretation of the data. 

Both human and 
computer perform 
ranking tasks, the results 
from the computer are 
considered prime. 

Computer allows the 
human a pre¬ 
programmed restricted 
time to veto before 
execution. Human 
shadows for 
contingencies. 

3 

The computer is 
responsible for gathering 
and displaying 
unfiltered, unprioritized 
information for the 
human. The human still 
is the prime monitor for 
all information. 

Computer is the prime 
source of analysis and 
predictions, with human 
shadow for 
contingencies. The 
human is responsible for 
interpretation of the data. 

Both human and 
computer perform 
ranking tasks, the results 
from the human are 
considered prime 

Computer executes 
decision after human 
approval. Human 
shadows for 
contingencies. 

2 

Human is the prime 
source for gathering and 
monitoring all data, with 
computer shadow for 
emergencies. 

Human is the prime 
source of analysis and 
predictions, with 
computer shadow for 
contingencies. The 
human is responsible for 
interpretation of the data. 

The human performs all 
ranking tasks, but the 
computer can be used as 
a tool for assistance. 

Human is the prime 
source of execution, with 
computer shadow for 
contingencies. 

1 

Human is the only 
source for gathering and 
monitoring (defined as 
filtering, prioritizing and 
understanding) all data. 

Human is responsible for 
analyzing all data, 
making predictions, and 
interpretation of the data. 

The computer does not 
assist in or perform 
ranking tasks. Human 
must do it all. 

Human alone can 
execute decision. 


Figure 6. Level of Autonomy Assessment Scale (Proud, et al., 2003, p. 4) 


The scale from Proud et al. they developed in Figure 6 also highlights one of the 
key elements missing from the Parasuraman et al. model (2000): the Parasurman et al. 

model lacked useful descriptions of what the exact interaction between human and 
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automation is supposed to be at eaeh level of automation in each the functions. The intent 
of the Proud et al. (2003) scale is “to help system designers easily and correctly identify 
the level of autonomy to design each function within their system. They are available for 
either identifying the level of autonomy of an existing function or for proposing an 
appropriate level of autonomy during the design of a new system. The OODA category 
aspect of this scale is advantageous because: 1) it allows more specific verbal description 
of the level of autonomy of a specific function than previous scales, and 2) it allows the 
function types to be weighted differently across a particular level. The second point is 
important to understanding the scale as a whole. A 5 in the Act column does not have the 
same costs, training requirements, or other assumptions as a 5 in the Orient column” 
(Proud et al., 2003, p. 5). The table developed by Proud et al. (2003) figures prominently 
in the proposed qualitative model along with the Pararsuraman et al. model (2000). 

3. LOA Research for Multiple UAVs 

Ruff, Narayanan, and Draper (2002) reported on an evaluation that compared 
effects of LOA and decision-aid fidelity on the number of UAVs that could be 
successfully controlled by one operator during a target acquisition task. Their LOAs 
included manual control, management-by-consent, and management-by-exception. The 
three LOAs corresponded to automation levels 1, 5, and 6 (respectively) from the 
Parasuraman et al. (2000) model (see Table 2). Dependent variables included mission 
efficiency, percentage correct detection of incorrect decision aids, workload and situation 
awareness (SA) ratings, and trust in automation ratings. Results indicated that an 
automation level incorporating management-by-consent (Sheridan LOA-5) had some 
clear performance advantages over the more autonomous (management-by-exception; 
LOA-6) and less autonomous (manual control; LOA-1) levels of automation. LOA-5 kept 
workload under control even with the operator controlling two or four UAVs, and SA 
scores were superior for LOA-5 across the number of UAVs controlled. 

Ruff et al. concluded that workload “does not abate as human tasks are 
automated” (2002, p. 348). Increasing automation to management-by-consent (LOA-5) 
maintains human-in-the-loop system functionality, but it reduces human responsibility for 
functions that humans do poorly (e.g., vigilant monitoring). Increasing automation to 
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management-by-exception (LOA-6) further removes the human from the decision¬ 
making process, lowering SA and making it more difficult for the human to make 
decisions when he or she is finally called upon. “Therefore, the foremost 
recommendation that stems from this study is the importance of an active role of the 
human operator in complex system decision-making processes” (2002, p. 348). 
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III. QUALITATIVE MODEL FOR THE DESIGN OF A HUMAN- 
AUTOMATION INTERFACE OF SYSTEM FUNCTIONS 


A. FIVE-STAGE MODEL FOR TYPES AND LEVELS OF AUTOMATION IN 

THE FCS MGV FLEET 

Given the available literature on design of automation and the opportunity to 
participate in the FCS MGV program through BAE-SC, a qualitative model is proposed 
to drive the functional architecture and the human-automation interface scheme on the 
MGV fleet. With this tool in hand, the exact role of the Soldier operators as the central 
component of the vehicle systems is clearly understood before the fielding of the vehicle 
systems. This is one way (among several) to work toward the ORD requirement for a 2- 
soldier crew. But, even if the 2-soldier crew requirement is relaxed, a coherent plan for 
automation will help to ensure soldier performance and system effectiveness. The focus 
of the model will be to ensure that a reduced-crew can perform well enough (not 
optimally) to accomplish all of the functions and tasks asked of the total vehicle system. 

The model proposed starts with Table 5, a five-stage model of information 
processing for the human-automation interaction scheme in the FCS MGV fleet. It stands 
squarely on the shoulders of a few giants in the field of human factors and automation 
research and development. It starts with the four-stage model proposed by Parasuraman 
et al. (2000) (see Figure 4). In addition, the LOA taxonomy from Endsley & Kaber 
(1999) (see Table 3) highlights the fact that option generation is an important facet of 
information-processing scheme for the MGV fleet and its soldier-operators (see Table 4). 

However, the term ‘generation’ from Endsley & Kaber (1999) does not quite 
capture the flavor of information-processing scheme in these Army vehicles. Instead, we 
turn to Army Field Manual 5-0 about the doctrine for the military decision making 
process (MDMP; see US Army, 2005). Army doctrine uses the term ‘Course of Action 
(COA) Development’ to describe both the generation and analysis of strategies to 
accomplish a mission, function, or task. So the five-stage model proposed in Table 5 
borrows the term ‘COA Development’ to better describe the particular function and lend 
the proper Army flavor to this model. 
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Table 6. Five-Stage Model of Information-Proeessing for Human-Automation 


Interaetion Scheme in the FCS MGV Fleet 


Stage 

Definition 


Information 

Acquisition 

Acquisition and registration of multiple sources of 
information. Positioning and orienting of sensory receptors, 
sensory processing, initial pre-processing of data prior to 
full processing, and selective attention 

2 

Information 

Analysis 

Conscious perception and manipulation of processed and 
retrieved information in working memory. Also includes 
cognitive operations (rehearsal, integration, and inference) 
occurring prior to point of decisions. 

3 

COA Development 

Generating (a) the decisions that need to be made, followed 
bv (b) formulating options or task strategies for achieving 
goals. 


Decision Selection 

Selection of a particular option, course of action (COA), or 
strategy to carry out. Decision(s) are reached based on the 
Analysis stage (cognitive processing), the COA 
Development stage, and expertise (human or software). 

5 

Action 

Implementation 

Consistent with the decision selection(s), carrying out the 
chosen option, COA, or strategy, whether through control 
actions at an interface or other means. 


Following the simple schematic from the Parasuraman et al (2000) model shown 
in Figure 4, the proposed human-automation interface model is shown graphically in 
Figure 7. This figure demonstrates the five stages of information processing, as well as 
the possibility for ten LOAs within each of the five stages. It retains the intuitiveness of 
the original model while allowing system engineers and designers to explicitly define 
how the human and proposed automation will interact. Hopefully, this approach will 
enable better understanding of how the two will perform as part of the overall system in 
development. We will return to a discussion of Functions A/A' and Systems B/B' 
momentarily. 
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FCS Manned Ground Vehicle Fleet (Common Crew Station) 


Acquisition Analysis COA Development Decision(s) Action(s) 


High High High High High 



Low Low Low Low Low 


Figure 7. Qualitative Model for Design for Human-Automation Interaetion in the 

FCS MGV Fleet. Note how the UA ‘Quality of Firsts’ are related to the proposed 
model. 


The final segment of the proposed human-automation interfaee model borrows 
from the Proud et al. (2003) model. Table 6 eontains a deseription of the proposed 
interaction between human and automation at each function of the five-stage model 
(Table 5) at each LOA. The descriptors in Table 6 are intended as an aid to system 
engineers and designers to understand the subtle changes in human-automation 
interaction with each change in LOA at each function. For instance, as a designer thinks 
about moving from LOA 3 to LOA 6 in the Analysis stage, he will have this table of 
descriptors to help understand the implications of that shift in terms of human-automation 
behaviors, roles, and responsibilities. The table’s descriptors also illustrate how human- 
automation compares between two different stages while at the same LOA. 


39 














Table 7. 


Descriptors for each LOA at each of the 5-stages of the proposed model 


Level 

Information 

Acquisition 

Information 

Analysis 

Generation 

Decision(s) 

Selection 

Action 

Implementation 


Automation uses 

Automation 

Automation 

Automation 

Automation carries 


internal and external 

predicts 

generates the 

selects best 

out decision(s) 


sensors to gather, filter, 

anticipated 

decision(s) to 

choice from its 

autonomously 


and prioritize data 

future events 

be made and 

own list of 

without delay. 


without displaying any 

using 

the CO As 

COAs. Does 

Human is 


information to the 

information 

available. 

not display 

completely out of 


human operator. 

from objects in 

Rank orders the 

selection 

the loop, and no 

10 


the environment, 
interprets and 
integrates data. 
Results are not 
displayed to the 
human. 

best choice 
(based on 
internal 
algorithm). 

Does not 
display to the 
human 
operator. 

justification 
process or 
choice to 
human 
operator 

intervention is 
possible. System 
does not even 
display that action is 
being implemented. 


Automation uses 

Automation is 

Automation 

Automation 

Automation 


internal and external 

an ‘information 

generates 

selects best 

executes action w/o 


sensors to gather, filter. 

manager’ that 

decision(s) to 

choice from its 

delay and only 


and prioritize data w/o 

predicts. 

be made and 

own list of 

informs the human if 


displaying any 

interprets, and 

applicable 

COAs. 

required by context 


information to the 

integrate data 

COAs. 

Displays the 

(or if automation 


human. Only displays 

into a result 

Displays best 

selection 

decides to). No 


“program functioning” 

which is only 

option to 

process only if 

override or 


flag to confirm system 

displayed to the 

human operator 

required by 

intervention is 


status; human monitors 
system status via flag, 
and takes over sensors 
if necessary 
(essentially moving 
down one level). 

human if result 
fit programmed 
context (context- 
dependent 
summary) 

only if asked 
for it. 

context. 

possible(?) 


Automation uses 

Automation is 

Automation 

Automation 

Automation 


internal and external 

an ‘information 

generates 

displays best 

executes w/o delay 


sensors to gather, filter. 

manager’ that 

decision(s) to 

choice from its 

and only informs 


and prioritize data w/o 

predicts. 

be made and 

own list of 

human of action if 


displaying any 

interprets, and 

applicable 

COAs. 

asked for it. 


information to the 

integrates data 

COAs. Rank 

Displays 

Override by human 


human. On request. 

into a result 

orders COAs 

selection 

is possible after 


displays status of sub¬ 

(context- 

for each 

process and 

execution starts; 


systems (sensors. 

dependent 

decision. 

result if asked 

human monitors for 

8 

comm, links, weapons, 
links, etc) for human to 
monitor. 

summary) which 
is only displayed 
if asked for by 
the human. 
Information 
integration 
augments human 
operator 
perception and 
cognition. 

Displays list 
(up to 5) only if 
human asks for 
it. 

by human 
operator. 

contingencies. 
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Level 


Information 

Acquisition 


Information 

Analysis 


Generation 


Decision(s) Action 

Selection Implementation 


7 

Automation uses 
internal and external 
sensors to gather, filter, 
and prioritize data. 
Displays filter and 
prioritized information 
to human. Also 
displays sub-systems 
statuses for human to 
monitor. Automation 
has primary control 
over sensors to scan 
and observe; human 
can take over sensor 
placement. 

Automation 
overlays 
predictions with 
analysis and 
interprets the 
data (simple 
summary, not 
context- 
dependent). The 
human is shown 
all of the results. 

Automation 
generates 
decisions to be 
made and 

CO As. Rank 
order CO As 
(by embedded 
algorithm or 
criteria), and 
displays the 
best option to 
the operator. 

Automation 
displays top 
recommended 
COA to human 
for yes/no 
decision. 

Automation 
executes w/o delay, 
informs the human 
explicitly, and 
allows for override 
after execution. 

Human monitors for 
contingencies. 

6 

Automation 
responsible to gather 
data via sensors and 
links. Displays only 
highlighted, prioritized, 
relevant information, 
along with sub-systems 
statuses. Automation 
has primary control 
over sensors to scan 
and observe; human 
can take over sensor 
placement. 

Automation 
overlays 
predictions with 
analysis and 
interprets the 
data. Human 
monitors the 
interpretation for 
contingencies. 

Automation 
generates 
decision(s) to 
be made and 
COAs and 
displays in 
recommended 
rank order (up 
to 5 COAs) to 
human 
operator. 
Operator may 
generate 
additional 
decision(s) and 
COAs, but not 
for input to 
computer. 

Automation 
displays up to 

5 COAs in 
rank order, 
from which the 
human must 
choose. 

Automation delays 
execution by a 
context-dependent 
amount of time that 
allows the human 
operator to veto the 
action before it is 
carried out. Human 
monitors for 
contingencies. 

5 

Automation 
responsible to gather 
data via sensors and 
links. Displays all data 
to human operator, but 
highlights prioritized, 
relevant information. 
Displays sub-systems 
statuses. Automation 
has primary control 
over sensors to scan 
and observe; human 
can take over sensor 
placement. 

Automation 
analyzes the data 
and makes 
predictions. 
Human 
completes 
interpretation 
and integration 
into information. 

Automation 
generates 
decision(s) to 
be made and 
COAs. 

Displays in 
recommended 
rank order (up 
to 5) to human 
operator. 

Human may 
generate 
additional 
decision(s) and 
COA(s) for 
input to 
computer. 

Automation 
displays up to 

5 COAs in 
rank order. 
Human 
chooses from 
this list, or 
from own list. 

Automation delays 
execution by a pre¬ 
programmed (fixed) 
amount of time that 
allows the human 
operator to veto the 
action before it is 
carried out. Human 
monitors for 
contingencies. 
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Level 

Information 

Acquisition 

Information 

Analysis 

Generation 

Decision(s) 

Selection 

Action 

Implementation 


Automation 

Automation is 

Automation 

Automation 

Automation 


responsible to gather 

the prime source 

generates 

displays full 

executes after 


data via sensors and 

for analysis and 

decision(s) to 

list of COAs in 

human operator 


links. Displays all data 

prediction. 

be made and 

recommended 

explicitly approves. 


to human operator, but 

Human 

COAs. 

rank order. 

Human monitors for 


highlights non- 
prioritized, relevant 
information. Displays 
sub-systems statuses. 

monitors, and is 
responsible for 
prediction and 
integration of 

Displays full 
list in 

recommended 
rank order to 

Human can 
choose from 
this list, or 
from own list 

contingencies. 

4 

Automation has 
primary control over 
sensors to scan and 
observe; human can 
take over sensor 
placement. 

data into 
information. 

human 
operator. 
Operator may 
generate 
additional 
decision(s) and 
COA(s) for 
input to 
computer (if 
needed). 

of COAs. 



Automation 

Automation is 

Automation 

Automation 

Human operator 


responsible to gather 

the prime source 

generates 

displays up to 

executes by minimal 


data via internal and 

for analysis. 

decision(s) to 

5 COAs in 

physical interaction 


external sensors; has 

displaying 

be made and 

random order. 

(e.g. 1-2 switch 


primary control over 

rudimentary 

COAs. 

Human selects 

actuation or button 


sensors to scan and 

results to 

Displays up to 

from this list. 

presses). 


observe. Displays 

monitoring 

5 COAs for 

or from his/her 

Automation ‘agents’ 


unfiltered, 

operators. 

each decision 

own list of 

track user interaction 

3 

unprioritized data to 
human operator; 
displays status of sub¬ 
systems (sensors, 
weapons, comm, links, 
CTP/COP). Human is 
still the prime monitor 
of all data; augments 
automation with own 
sensory receptors. 
Human has the ability 
to take over sensor 
placement from 
automation. 

Human operator 
responsible for 
all prediction, 
interpretation, 
and integration. 

in random 
order to human 
operator (by 
design, or if 
ranking 
algorithm not 
available). 
Human may 
generate 
additional 
decision(s) and 
COA(s) for 
input to 
computer. 

COAs. 

with computer and 
execute all sub-tasks 
automatically (i.e. 
batch processing). 
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Level 

Information 

Acquisition 

Information 

Analysis 

Generation 

Decision(s) 

Selection 

Action 

Implementation 


Human is the prime 

Human is the 

Automation 

Automation 

Human operator 


source for sensing, 

prime source for 

generates 

displays 

executes by 


monitoring, and 

analysis. 

decision(s) to 

complete set of 

extensive, indirect 


prioritizing data. 

prediction. 

be made and 

decision/ 

physical 


Human positions 

interpretation. 

COAs. 

action 

manipulation of 


sensors (own, internal. 

and integration 

Displays full 

alternatives. 

necessary sub¬ 


and external) as part of 

of data into 

list of COAs 

Human selects 

systems (e.g. 


selection attention; has 

information. 

for each 

CO A from the 

teleoperation. 


full control of sensors 

Automation only 

decision in 

full list, or 

remote operations. 


in order to scan and 

displays raw 

random order 

from own list 

slaving of human 


observe. Automation 

data values from 

to human 

of COAs. 

physical action. 

2 

tracks status of relevant 
sub-systems (sensors, 
CTP/COP, weapons, 
comm links) but does 
not display; shadows 
for emergencies(?). 

sensors and links 
to help human 
operator. 

operator (by 
design, or if 
ranking 
algorithm not 
available). 
Human may 
generate 
additional 
decision(s) and 
COA(s) for 
input to 
computer. 


virtual 

environments). 


Human is the only 

Human performs 

Human 

Human selects 

Human operator 


source for sensing and 

all perception 

operator 

choice from 

carries out the 


registration of input 

and cognitive 

generates 

his/her own list 

decision, directly 


data; filters, prioritizes. 

processing. 

decision(s) to 

of COAs, with 

and physically 

1 

understands. 

making 

predictions and 
interpretation of 
data, or 
integrating 
several variables 
into a single 
value. No 
information 
available from 
automation. 

be made and 
the available 
COAs. No 
assistance from 
automation. 

no assistance 
from 

automation. 

implementing all 
aspect of the chosen 
action with no 
interaction or help 
from automation. 


Referring back to Figure 7, let’s look at the examples of Functions A/A' and 
Systems B/B' on the graphical scheme. Function A might represent one proposed way to 
describe the human-automation interaction for this particular function as it proceeds from 
information acquisition to analysis and on through to decision selection and action. 
System designers have deliberately designed this interaction as a way to understand how 
the two components will interact, and also to conceptually understand what exactly the 
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automation should be designed and built to do as it aids the human operator. However, 
they also would like to look at the alternative of Function A', another way of deliberately 
describing the interaction. This example shows the utility of the proposed model as 
modified from Parasuraman et al. (2000) for the MGV fleet. The graphical representation 
of human-automation interface makes it particularly easy to envision the overarching 
functional architecture of a system or function to understand exactly how a human will 
interact with the proposed automation. Like the slider bars on your stereo equalizer, the 
designers could simply ‘slide down’ the LOA on several of the functions. Combined with 
the descriptors in Table 6, designers can clearly understand the new relationship between 
human and automation throughout the entire Function AJ A'. Likewise, System B/B' 
may represent a much smaller system that can be looked at as whole from information 
acquisition through to the decision and action stages. In this case, designers might be 
thinking about introducing more automation to the small system, and can use the 
graphical representation in Figure 7 along with the descriptors in Table 7 to better 
understand the resulting relationship between human and automation in their new 
proposal. 

B. APPLICATION OF MODEL TO MGV FUNCTIONAL FLOW 

The next step in the thesis is to exhibit how the proposed qualitative model might 
be applied against the functional flow that describes MGV operations. The human 
factors group at BAE-SC has developed a FA/TA and functional flow for the CCS of the 
MGV fleet. The FA/TA provides an overall reference on how the Army and the V.I. 
envision the total vehicle system to operate. As such, the FA/TA is currently indifferent 
as to the allocation of functions and tasks between the hardware/software components of 
the system and the human crew. Using the FA/TA and functional flow provided from 
BAE-SC engineers. Figure 8 shows a top-level view of the five functions envisioned for 
the CCS in what is being called the Common Function Model (CFM). The five functions 
thought to be common to the entire MGV fleet are vehicle movement (driving), 
communication, vehicle commander’s awareness, driver’s local surveillance, and local 
defense. This thesis will focus on applying the proposed qualitative human-automation 

interaction model to the last of these, the Local Defense function. 
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Figure 8. CFM Function Flow - Level 1. 


Figure 9 shows a further decomposition of the functional flow to a secondary tier 
that will be called level two. Notice that the Function 5 (Local Defense) has two 
subfunctions called Acquire/Track Threat and Engage Threat. 
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Figure 9. CFM Functional Flow - Level 2 
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Figure 10 shows a third-tier decomposition of the Local Defense only into a series 
of tasks; this is the final decomposition. The tasks contained in Function 5.1 
(Acquire/Track Threat) are displayed underneath its bubble, as are the tasks for Function 
5.2 (Engage Threat). The tasks involved preparing and transmitting a digital SITREP 
(situation report) are repeated in both tasks depending on the flow. 
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Figure 11 goes one step further to collect the decomposed tasks into groups that 
adhere to the information processing model proposed in Table 5. 



Using the functional flow for Local Defense graphically shown in Figure 11, the 
next step is to then apply it against the proposed model for MGV human-automation 
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interaction shown in Figure 7. The result is the proposed schematic in Figure 12. Here 
we can begin to understand the possible relationship between human and automation in 
the Local Defense function. 
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Figure 12. Local Defense (CFM 5) decomposed into the proposed qualitative model 


At this point in the process, we can now begin to purposely design the interaction 
between the human operators and a conceptual automation scheme, or to quote 
Parasuraman et al., we can begin to ask “what level of automation should be applied 
within each functional domain. There is no simple answer to this question, and tradeoffs 
between anticipated benefits are likely” (2000, p. 289). The graphical model in Figure 12 
and the descriptors in Table 7 are proposed as a guiding framework. Evaluative criteria 
will be discussed below, but three clusters of sources can help to begin the process. The 
first is prior empirical research, such as that reviewed earlier from Kaber and Endsley 
(2004) and Ruff et al. (2002). “To take a hypothetical example, suppose prior research 
has shown (or modeling predicts) that, compared to manual operation, both human and 
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system performance are enhanced by level 4 automation but degraded by automation 
above level 6” (Parasuraman et al, 2000, p. 290). This could serve as an initial 
specification for the upper and lower bounds of automation in a certain function. 
Research sources include the writings from experienced researchers in the field who have 
delved into real automation and resulting human accidents, such as Billings (1997), 
Norman (1990), Woods and Sarter (1998). The second cluster looks to Army doctrine 
and past experience from tactics, techniques and procedures (TTPs), which can guide us 
as to understanding what has (and has not) worked in past and current systems. Closely 
related is the third cluster, input from subject matter experts (SMEs). SMEs may be real 
soldiers who work in the combat development or material development structures for the 
Army. They can also include the experience and expertise of scientists and engineers who 
have been involved in systems design in the past, particularly human factors specialists. 

Therefore, to further the ideals of this thesis. Figure 13 graphically presents two 
possible human-automation interface schemes to achieve the common function of Eocal 
Defense. The current scheme (yellow line on the graph) employs almost no automation 
at all, only giving the vehicle commander some physical aids to allow arming and firing 
of the chosen weapon with a single button press. The vehicle commander is totally 
responsible for detecting, identifying, and tracking any local threats. Unfortunately, the 
common FA/TA provided by BAE-SC does not account for the COA Development stage 
proposed in this thesis, so it is skipped and simply left at full manual control. In the 
Engagement stage, the commander must then make a series of decisions (probably in 
rapid order) that starts with whether to engage the target or not, followed by selections of 
the appropriate weapon and ammunition. At the Shoot/Report stage, automation design 
gives the commander some physical help by only requiring a simple button press to arm 
the chosen weapon, and then another single-button press to fire the weapon. Preparation 
and transmission of the digital (i.e. typed text) situation report is left completely with the 
commander. 
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FCS Manned Ground Vehicle Fleet (Common Crew Station) 
Local Defense (CFM 5): Acquire/Track/Enqaqe Threat (CFM 51-52) 



Figure 13. Qualitative Model Applied to the Local Defense Function 


In contrast to the current scheme, a new proposal for human-automation is 
graphically represented in Figure 13 with the red line. Notice that, per the description of 
the model in Figure 7, the ‘slider bars’ are up to higher LOAs for certain tasks in the 
Local Defense function. The new proposal blends some prior research, some SME input, 
and some human factors knowledge. 

Starting with the Detection and Identification tasks, the interface is moved up to 

LOA-3 in accordance with the descriptors in Table 6. Upon reflection about the Tracking 

task, it was decided that the soldier simply monitoring any proposed automation would 

require just as much mental workload effort and doing it himself, so it is left unchanged. 

Moving to the Engagement tasks, the human will get some help in making the decision to 

engage or not. After that, it is hypothesized that an intelligent automation scheme would 

quickly make the correct recommendation for the appropriate weapon and ammunition 

based on sensor data. If the commander decides not to engage the target, he would move 
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straight away to the SITREP preparation and transmission. Finally, as the functional flow 
continues, computer software would ask the commander if he wants to arm the chosen 
weapon. Then the commander can fire the weapon with a single button press (no change 
from the current scheme). To end the sequence, the commander would get considerable 
aid in preparing and transmitting the SITREP, a big change from the current system. Of 
course, the entire sequence feeds back on itself and repeats, as dictated by the operational 
situation. 

There are four dashed arrows in the proposed human-automation scheme that 
require some explanation. For the two decisions at LOA-7, the proposed interface would 
entail the computer making a recommendation to the vehicle commander for a yes-or-no 
decision. If the human accepts the recommendation, the next task occurs. However, for 
these two decision tasks, if the commander rejects the recommendation, then the scheme 
reverts to LOA-1, the same as the current scheme. For the task of arming the chosen 
weapon, a similar scheme results. If the vehicle commander decides to reject (or 
override) the arming of the weapon, then the interaction reverts to LOA-1. Lastly, the 
computer will prepare a SITREP based on available data and transmit automatically 
unless the commander rejects (or overrides) the preparation/transmission task, causing a 
reversion to LOA-1. 

The white boxes at the bottom of each of the five stages in Figure 11 depict basic 
pieces of information about what might be displayed to the vehicle commander at that 
stage of the functional flow. In the Detection stage, the commander will probably need to 
see the proper symbology of all targets, the status of his vehicle’s sensors, and status of 
the common operational picture (COP), common tactical picture (CTP), and any 
communications links to the network. In the Identification/Track tasks, the commander 
will likely need to have further information about the target, such as location, bearing, 
speed, even altitude. Information for any of these stages may come from the vehicles own 
sensors, from the COP, or over the network. In the COA Development stage, the 
commander will need to see the possible COAs, depending on the LOA used. In a slight 
shift, the white boxes below the Engagement and Shoot/Report tasks each delineate 
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exactly what decisions have to be made, and what actions must be carried out. These 
decisions and actions can be accomplished by the soldier-automation team. 


C. APPLICATION OF MODEL TO LITTORAL COMBAT SHIP 

The example detailed in the previous section is for only one function of the 
common crew station for the MGV fleet. In an attempt to provide the reader with another 
example of how this process might be carried out in another domain, Appendix B of this 
thesis contains an example of the Parasuraman et al. (2000) model of human-automation 
interface applied to the US Navy’s Littoral Combat Ship. 

The paper included in the Appendix was developed as a conceptual project for a 
course in Systems Engineering and Integration at the Naval Postgraduate. The paper was 
published in the proceedings of the 2005 Human Systems Integration Symposium (see 
Kennedy, Thomas, & Green, 2005). 


D. EVALUATIVE CRITERIA 

Borrowing once again from Parasuraman, Sheridan, and Wickens (2000), any 
particular “level of automation should be evaluated by examining its associated human 
performance consequences. However, human performance is not the only important 
factor. Secondary evaluative criteria include automation reliability and the costs of 
decision/action consequences” (p. 289), though others may include ease of systems 
integration, efficiency/safety tradeoffs, issues of operators, and more. “These should be 
applied to evaluate the feasibility and appropriateness of particular levels of automation” 
(p.289), done in an iterative process. They emphasize, however, that the model should not 
be treated as a static formula or as a prescription that decrees a particular type or level of 
automation. Rather, when considered in combination with primary and secondary 
evaluative criteria, the model they provided, and expanded in this thesis, “can provide 
principled guidelines for automation design” (p. 289). 

1. Primary Criteria 

Over the past 25 years, researchers have found that automation can have both 
beneficial and negative effects on human performance. There are four main human 
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performance areas recommended by Parasuraman et al. (2000) as primary evaluative 
criteria: mental workload (MWL), SA, complacency, and skill degradation. Evidence 
suggests that well-designed information automation can change MWL to a level that is 
appropriate for the systems tasks being performed. However, “clumsy” automation can 
lead to increasing workload (2000). As will be discussed below, MWL can be modeled 
during system design to assess if it is reasonable throughout system functional flow. 

Besides unbalanced MWL, automation can incur human performance costs in the 
other three criteria suggested. Situation awareness can be negatively affected when the 
operators loses “awareness of the system and certain dynamic features of the work 
environment” (2000, p. 291). If the MGV automation scheme is highly but not perfectly 
reliable in executing the major decision choices, “then the operators may not monitor the 
automation and its information sources and hence fail to detect the occasional times when 
then automation fails” (2000, p. 291) or is wrong. Complacency is greatest in high MWL 
setting when the operator is engaged in multiple tasks. Third, skill degradation can 
certainly occur over time if the system decisions are routinely carried out by the 
automation. “These potential costs—^reduced situation awareness, complacency, and skill 
degradation—collectively demonstrate that high-level automation can lead to operators 
exhibiting out-of-the-loop unfamiliarity. All three sources of vulnerability may pose a 
threat to safety in the system failure” (2000, p. 291). The MGV automation design must 
demonstrate that potential human performance costs, along with unbalanced MWL, do 
not occur. “By considering these human performance consequences, the relative merits of 
a specific level of automation can be determined” (2000, p. 291). 

2. Secondary Criteria 

Secondary evaluative criteria can include automation reliability and the cost of 
decision and action outcomes. Reliability is typically defined in probabilistic terms, such 
as a reliability of .997 or a mean time to failure of 10,000 hours. In addition, “failures 
may occur not because of a predictable (in a statistical sense) malfunction in software or 
hardware, but because the assumptions that are modeled in the automation by the 
designer are not met in a given operational situation” (2000, p.292). The reliability of 
automation also influences human trust, possibly undermining potential system 
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performance benefits when the automation is underused or disabled. In addition to 
reliability, “assessing the appropriate level of automation for decisions requires additional 
consideration of the costs associated with decision and action outcomes” (2000, p. 292; 
see also Lee and See, 2004). 
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IV. THE HUMAN-AUTOMATION INTERFACE MODEL IN 
ACTION: A QUANTITATIVE IMPLEMENTATION VIA IMPRINT 

A. NEED FOR QUANTITATIVE MODELS 

Parasuraman et al. (2000) correctly argue for the primary evaluative criteria as 
part of the design process for a human-automation interaction scheme. As discussed in 
Chapter II of this thesis, Parasuraman (2000) also argued for the development of 
quantitative models that could inform the design of human-automation interaction, 
pointing out several computational and formal models of human interaction with 
automation. 

This thesis implemented the qualitative model applied to the MGV (per Chapter 
III) via a computational analysis using task-network modeling and Monte Carlo 
simulation from a software called IMPRINT (see below for details). This demonstration 
is a way to quantitatively predict human task-loading attempts to evaluate the primary 
criterion of mental workload. There is one example in the literature from Parasuraman et 
al. (2005) where a automation scheme has been modeled via a computational task- 
network model. In the study, the research team investigated the effects of a delegation- 
type interface on human supervision of multiple unmanned vehicles. As part of the 
experimentation program, they conducted analysis via WinCrew to carry out a mental 
workload prediction (personal communication. Dr. Hiroshi Furukawa, 20 Sep 05). 
WinCrew is a precursor to the program MicroSAINT, which is the heart of ARL/HRED’s 
IMPRINT software. The Parasuraman et al. (2005) paper provided the inspiration to 
demonstrate the proposed MGV human-automation guidelines in IMPRINT. 


B. IMPROVED PERFORMANCE RESEARCH AND INTEGRATION TOOL 
(IMPRINT) 

IMPRINT is a stochastic network-modeling tool designed to help assess the 
interaction of soldier and system performance from concept and design through field 
testing and system upgrades. An important feature of IMPRINT is that it helps 
researchers and designers evaluate operator and crew mental workload while testing 
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alternate system-crew function allocations. The amount of mental workload that is 
required to use a system has a significant effect on human performance within the 
system. IMPRINT gives system designers the information they need to predict how 
changes in design can affect overall system performance. Since PCS is still early in the 
design phase, IMPRINT is a very suitable tool to use (Mitchell, Samms, Henthom, & 
Wojciechowski, 2003; Mitchell, 2005). 

One major function of IMPRINT, via task-network modeling, is to predict 
operator task-loading using cognitive resources (visual, auditory, cognitive, motor, and 
speech) and Monte Carlo simulation. This provides quantitative values for total 
momentary workload based on the estimates of cognitive resources provided by the 
analyst. The IMPRINT methodology has a long history in the Army, originated during 
the early days of the LHX program as discussed in Chapter II. Without a doubt, the 
accuracy and precision of the modeling results depend on the skill and experience of the 
analyst (as they say. Garbage In—Garbage Out). However, it is a well accepted modeling 
methodology in use by multiple Army (and DoD) programs. 

The task-network model in IMPRINT is generally run for a set period of time; 
anywhere from one minute to several hours, depending on the needs of the analyst. The 
models generated for this thesis were set to run for 60 minutes. To run the simulation for 
the set time, the analyst provides a random number seed to the program, an integer from 
1-100,000. In effect, the random number seeds simulate the variation that would normally 
be provided by different human subjects. IMPRINT provides a host of numerical results 
straight to Microsoft Excel for further scrutiny. Chief among these is the total 
momentary workload score calculated each time a tasks begins or ends. The advanced 
workload feature of IMPRINT used in this analysis calculated workload based on the 
cognitive resources being used by the operator, and incorporates the fact that multiple 
tasks are being performed simultaneously. 

Previous technical reports and publications from ARL/HRED using IMPRINT 
have incorporated a workload ‘threshold’ value where the operator was considered to be 
a state of ‘high’ or ‘very high’ workload. This concept of a workload threshold goes 
back to the original LHX analysis from McCracken and Aldrich (1984). The IMPRINT 
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workload value of 60 has been used by a consensus of workload modeling SMEs to 
represent the ‘high’ threshold, while the workload value of 100 is equivalent to the ‘very 
high’ threshold (Mitchell, Samms, Henthom, & Wojciechowski, 2003; Mitchell, 2005). 

Previous technical analysis by IMPRINT modelers for the PCS MGV fleet has 
yielded five metrics of use in the IMPRINT analysis: 1) maximum momentary workload 
calculated during the data run, 2) number of times in the simulation run that workload 
exceeded 60 (high), 3) number of times that workload exceeded 100 (very high), 4) the 
percentage of time spent over the high threshold, and 5) the percentage of time spent over 
the very high threshold. These five metrics are used in this thesis. 


C. MGV COMMON FUNCTION MODEL (CFM) 

IMPRINT analysts with ARL/HRED, the ECS LSI (Boeing, SAIC) and the V.I. 
team (BAE and GDLS) have developed a CFM based on the CCS FA/TA discussed 
earlier. The CFM model is generally approved by all of the analysts involved in the 
project, and has been through the scrutiny of multiple SMEs to ensure it is a valid 
representation of the task-network and functional flow anticipated for crews in the CCS 
of the MGV fleet. This model, provided by analysts from BAE to the author, acts as the 
baseline for the task-loading analysis in this thesis. 

Using the proposed scheme in Figure 13, the Local Defense function (CFM5) of 
the baseline was modified to reflect the new and resulting human-automation scheme by 
‘dialing in’ selected levels of automation for selected tasks. The exact task-network 
changes are not reproduced here, but Figure 14 is provided to give the reader an 
understanding of how the Local Defense task-network in the CFM was modified to 
account for the proposed human-automation interaction. The full task-network model is 
available electronically from the author on request. 
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While IMPRINT is a great tool for early analysis, it cannot fully capture the 
nuances of the proposed human-automation interface in the estimates of cognitive 
resources, task completion times, etc. IMPRINT is limited in its ability to fully model the 
interaction and subsequent operator human, but its results do provide some bounds and 
guidance on the real problem of crew size and paired human-automation behavior in the 
MGV fleet. 
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To collect baseline data for the analysis, the simulation was run for 60 minutes. A 
set of random number seeds were generated in Microsoft Excel for use in the random 
number seed part of the simulation. After inputting the random number seed and 
executing the baseline CFM model, it took approximately 2-5 minutes to complete the 
simulation and generate the data into Excel. Then another random seed was entered and 
the simulation run again, continuing this process a dozen times to get a set of usable data 
that the author felt comfortable with. 

As with the baseline CFM model, simulation was run for 60 minutes to permit 
side-by-side comparison of the five workload metrics. However, completing the data 
runs for the modified CFM was a much longer, more involved process. First attempts at 
modifying the CFM involved breaking each baseline tasks into two or more tasks, which 
were carried out by human and automation in parallel in the task network. The subtasks 
assigned to automation were carried out without error in no time and with no workload 
channel values. The subtasks assigned to the human were given modified workload 
channel values based on the nature of the resulting interaction with automation. This 
process of assigning new tasks and workload values carries as much ‘art’ as it does 
‘science’. It is entirely up to the modeler, with his experience and expertise, to guide the 
process. After some early data runs, the author realized the method of having the 
subtasks in parallel was causing unintelligible results: all of the workload results were in 
the many, many times in excess of the baseline CFM scores, indicating a serious problem 
with the veracity of the model. 

Realizing this was an error, the author then shifted to running the resulting 
subtasks in serial. Repeated modifications of the model and about an additional 60 data 
runs were necessary before IMPRINT yielded intelligible results. Further modifications 
to the task-network eventually were necessary to capture the some of the intricacies of the 
proposed human-automation interaction and predicted task-loading (i.e., MWL, a key 
component of human performance). All told, the author completed over 250 data runs. 

Once the author was comfortable with the execution of the modified CFM, the 
author ran another set of eleven data runs using the same random number seeds as the 
baseline analysis, and then tabulated the scores for five chosen metrics. In effect, using 
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the same random seeds simulated using the same human subjeets for both the baseline 
and modified CFM. This is a key varianee reduetion teehnique, and allowed a side-by- 
side comparison of the baseline CFM versus the modified CFM. 

D. PLAN FOR QUANTITATIVE ANALYSIS 

Given the baseline-modification plan of action, the plan for data analysis was 
straightforward. In this case, the baseline CFM and the proposed modifications represent 
a classic ‘before-after’ comparison, and the paired t-test is appropriate. The data for the 
five metrics collected above (maximum workload, number of time over 60 and 100, 
percent of time over 60 and 100) were compared via the paired t-test. The data certainly 
displayed interval/ratio scale properties. The assumption of normality in the paired 
differences was reasonable for three of the metrics, but somewhat weak for two others. 
Thus, the five before-after metrics were also compared via the equivalent nonparametric 
inferential statistic, the Wilcoxon Signed Ranks Test (WSRT). The conclusions were the 
same regardless of the test conducted. 
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V. RESULTS OF QUANTITATIVE ANALYSIS VIA IMPRINT 


Eleven data runs were eonducted each for the baseline MGV CFM as well as the 
modified CFM with the proposed human-automation interface scheme out of Figure 11. 
Table 8 shows the tabulated results from the baseline CFM, while Table 9 shows the 
tabulated results for the modified CFM. Each simulation run was conducted eleven times 
with the common random number seeds. The sample mean and standard deviation are at 
the bottom of each table to gain an understanding of the variability in the data. 


Table 8. Analysis of Baseline 

MGV CFM 

Run 

Maximum 

Workload 

Number of Times 
Workload 
Exceeds (>) 60 

Number of 
Times Workload 
Exceeds (>) 100 

Percent of Time 
Over High 
Threshold (> 60) 

Percent of Time 
Over Verv High 
Threshold (> 100) 

1 

297.26 

792 

401 

46 . 22 % 

21 . 44 % 

2 

428.76 

751 

449 

49 . 15 % 

24 . 72 % 

3 

451.88 

1055 

723 

64 . 58 % 

39 . 36 % 

4 

589.65 

2614 

2254 

85 . 94 % 

72 . 65 % 

5 

1100.08 

3381 

3200 

87 . 03 % 

80 . 25 % 

6 

412.11 

847 

469 

49 . 02 % 

24 . 15 % 

7 

213.33 

627 

233 

35 . 32 % 

11 . 43 % 

8 

353.92 

1222 

820 

67 . 24 % 

40 . 75 % 

9 

586.23 

926 

588 

52 . 84 % 

31 . 63 % 

10 

284.02 

581 

232 

34 . 01 % 

11 . 68 % 

11 

431.67 

812 

514 

49 . 22 % 

28 . 48 % 

X 

468.08 

1237 

898 

56 . 41 % 

35 . 14 % 

A 

245.70 

941 

981 

18 . 57 % 

23 . 26 % 


Comparison of the five metrics via paired t-test yielded statistically significant 
differences in four of the five metrics (Table 9). The number of times workload exceeded 
60 and 100, and the percentage of time workload was over 60 and 100, were significantly 
lower in the modified CFM than in the baseline CFM. The difference in maximum 
workload was not significant. 
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Table 9. Analysis Results of Proposed Human-Automation Interface Scheme 


Applied to MGV CFM 


Run 

Maximum 

Workload 

Number of Times 
Workload 
Exceeds (>) 60 

Number of Times 
Workload 
Exceeds (>) 100 

Percent of Time 
Over High 
Threshold (> 

60) 

Percent of Time 
Over Very High 
Threshold (> 100) 

1 

270.14 

538 

231 

34.06% 

11.79% 

2 

382.25 

680 

372 

31.02% 

13.34% 

3 

675.88 

924 

585 

49.16% 

28.06% 

4 

444.44 

997 

655 

57.60% 

38.81% 

5 

808.38 

2568 

2311 

85.32% 

75.89% 

6 

497.86 

1170 

767 

65.72% 

38.38% 

7 

213.33 

603 

236 

33.45% 

10.91% 

8 

420.67 

803 

422 

44.47% 

21.06% 

9 

208.5 

479 

215 

30.21% 

11.61% 

10 

262.82 

487 

218 

27.83% 

10.39% 

11 

216.63 

485 

201 

27.05% 

9.98% 

X 

400.08 

885 

565 

44.17% 

24.57% 


413.08 

920 

598 

45.18% 

25.84% 


able 10.Results of Comparison by Paired Mest 


Metric 

Mean 

Difference 

SE Mean 

t 

df 

/7-value 

Maximum Workload 

68.00 

53.05 

1.282 

10 

.229 

Number of Times > 60 

352.182 

153.57 

2.293 

10 

.045 

Number of Times >100 

333.636 

155.57 

2.145 

10 

.058 

Percent of Time > 60 

12.24% 

3.95% 

3.102 

10 

.011 

Percent of Time >100 

10.57% 

3.84% 

2.756 

10 

.020 


Since the assumption of normality in the paired differences was weak in two 
cases, comparison of five metrics was also conducted via the WSRT (Table 10). The 
conclusions are the same as the paired t-test results. 


Table 11. 


Results of Comparison by Wilcoxon Signed Ranks Test 


Metric 

T 

/7-value 

Maximum Workload 

1.282 

.285 

Number of Times > 60 

2.293 

.016 

Number of Times >100 

2.145 

.021 

Percent of Time > 60 

3.102 

.016 

Percent of Time >100 

2.756 

.021 
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VI. DISCUSSION 


A. DO NOT OVEREMPHASIZE THE STASTICAL RESULTS 

The goal of this thesis was to provide a process for developing a top-down, 
overarching approach to explicitly define and design the interaction between proposed 
automation schemes and the human crew. It shows an approach to developing a 
functional architecture between human and automation for the total system. In effect, it 
constitutes the design methodology and automation philosophy, as espoused by Rouse et 
al. (1987). While it was developed for engineers and scientists at BAE and the V.I., the 
process can be expanded to a wide array of domains (aviation, space, maritime, ground 
transportation, manufacturing, etc.). Chapter III covered the development of the 
qualitative to drive the design process. It is a logical approach to function decomposition 
with a reasonable paradigm to use to conceptualize the shared roles between human and 
automation. With this tool in hand, the exact role of the Soldier operators as the central 
component of the vehicle systems can be more clearly understood well before the fielding 
of the vehicle systems. 

The results show that it is possible to gain a reduction in operators task-loading, 
but is not inevitable. Using IMPRINT, we associate task-loading with the construct of 
mental workload, an idea that cannot be easily measured under any circumstances. The 
research community generally accepts MWL as a key facet of overall human 
performance, but simply lowering MWL will not necessarily improve human (and thus 
system) performance. Simply adding more automation will not automatically decrease 
task-loading and mental workload. The literature review in this thesis should convince 
the reader of these assertions. 

The thesis demonstrated that the proposed model can be implemented in 
IMPRINT as a way to quantify the effects of the proposed human-automation interface 
scheme on task-loading predictions (and thus mental workload). Only the Local Defense 
function of the CFM was quantitatively modeled, but it helps us gain some understanding 
of the human performance ramifications of the proposed model, as per the primary 
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evaluative criteria put forth by Parasuraman et al. (2000). In this way, we can take a step 
towards reducing workload peaks and improving human performance. 

A primary conclusion of the thesis is that by applying the proposed human- 
automation interface model to other functions in the vehicles, both in the CFM and in 
vehicle-specific function, it is possible to make further reductions in operators task¬ 
loading, and this MWL. This will also support attempts to achieve the current ORD 
requirement for a vehicle operable by a 2-soldier crew. This work is intended to 
contribute to the effort to ensure that vehicle systems in the MGV fleet can accomplish 
the overall unit mission and the PCS’ mission as an acquisition program. Even if we 
eventually conclude that an additional crewmember is required on the various MGV 
vehicles, the same qualitative and quantitative models can be used to gain a clear 
understanding of the human-automation interaction as well as the some of the human 
performance ramifications in terms of mental workload. 

Caution should be taken not to overemphasize the results of the paired 
comparisons in the Results. Again, the goal of the thesis was to demonstrate how the 
proposed interface scheme might be quantitatively modeled. There are many 
knowledgeable IMPRINT practitioners who can improve on the steps taken in this thesis 
to quantify the possible human performance ramifications. Echoing previous IMPRINT 
technical reports and papers (Mitchell, 20005; Mitchell et al, 2003), this type of 
quantitative analysis can direct the engineer and researcher towards areas of task demand 
in new, manned systems that need improvements. 

Another key point to make about the possible reductions in task-loading (and 
thus, MWL) is to understand that they are possible if, and only if it is possible to design 
the automation to the levels reco mm ended in the proposed model! If the proposed 
automation level is not technically feasible, or costs too much to achieve, then you may 
not be able to achieve the predicted operator task-loading predictions. Should engineers 
and designers be forced to ‘dial down’ the LOA for a function, modifying the IMPRINT 
analysis is a possible way to understand the implications on task-loading, and thus 
possible ramifications for human performance. 
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There is a final note of eaution in interpreting the results. In the midst of making 
the 250+ data runs in IMPRINT with the different random number seeds, there were 
several eases of extreme outliers in terms of caleulated task-load, with maximum 
workload seores reaching in excess of 2000 on one or two occasions. It merely goes to 
show that IMPRINT, while a wonderful tool for analysis of systems early in the design 
process, has inherent variability and that multiple runs with common random number 
seeds are necessary achieve accurate estimates of workload. 

The author is firmly convinced that if he took the time to replicate the analysis 
over 40-50 data runs (with common random number seeds to reduce variability and 
induce the paired t-test), that the results would yield at least 3-5 severe outliers in terms 
of workload score. Post-hoc analysis of some outlier cases shows that the simulated 
vehicle commander was trying to accomplish unrealistic number of tasks simultaneously. 
In some instances, not only was the commander conducting various tasks in the Local 
Defense function, but the simulation might have the same person monitoring the driver, 
talking on the intercom, typing a digital message, and more. This artificially drives the 
momentary workload score into unrealistic totals. In real operations, the vehicle 
commander would have shed and/or prioritize tasks in order to bring his workload under 
some semblance of control. To paraphrase legendary Frederick Taylor, the ‘father of 
scientific management’, he would be required to have too many hands, too many feet, 
and too many heads (Taylor, 1957). 

Post-hoc analysis of other outlier cases reveals another situation that IMPRINT 
analysts must be wary of This thesis made modification to only the Local Defense part 
of the CFM, leaving the remaining functions unchanged. There was one case during 
early data runs where a certain random number seed simply never called upon the Local 
Defense function, even after 60 minutes of simulated action. In that case, the total 
workload metrics became severe outliers because the simulation never called on the 
functions where automation had been ‘dialed in’ to help the human operator! In that 
case, the random number seed and its results were discarded. The prudent practitioner 
will not make conclusions from only a single data run, but rather after at least 10 data 
runs to gain some idea of the variability involved the simulation. 
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B. WHAT IMPRINT DOES NOT ACCOUNT FOR 

The results of this thesis should not be construed as an argument that the MGV 
fleet can be operated with only two soldiers. Nowhere does this thesis make that 
argument or conclusion. While the thesis has been able to show how the application of 
the qualitative human-automation interaction model can bring a possible reduction in 
operator task-loading due to purposely designed automation features, it would be a 
serious (and unfounded) leap of logic to conclude that it can ensure adequate human 
performance by a two-soldier crew. 

The CFM analysis via IMPRINT concentrates wholly on combat operations in the 
MGV common crew station, arguably the most intense and cognitively difficult mission 
segment of the MGV fleet. However, the IMPRINT models do not account for a host of 
other functions that the MGV fleet and its crew members will take on outside of combat 
operations that can be very demanding, both mentally and physically (personal 
communication, John Lockett, 27 September 2005). It would be careless not to point out 
that the models, in their present state, do not even attempt to account for activities such as 
crew rest (sleep), performance under fatigue, environmental taxons such as heat, cold, 
and/or chemical-biological warfare environment. The models do not account for physical 
labor required in certain resupply and logistics operations, where an extra crew member 
may be invaluable in loading, unloading, or cross-loading of ammunition, food, water, 
and other supplies. Lastly, the model, running only 60 minutes, does not attempt to 
understand how crews would perform and rest under long-tem operations, such as the 72- 
hour mission profde dictated in the PCS O&O Plan and ORD. 


C. HSI (MANPRINT) DOMAINS - IMPLICATIONS AND TRADEOFFS 

The proposed human-automation interface scheme for the MGV fleet can 
contribute to multiple HSI (MANPRINT) domains that will require trade-off analysis to 
resolve. We can anticipate impacts to nearly all of the domains, including Manpower, 
Personnel, Training, Human Factors Engineering, System Safety, and Soldier 
Survivability (see US DoDI 5000.2, pp. 32-33, and US Army Regulation 602-2 for 
details of the HSI/MANPRINT domains and their definitions). 
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1. Manpower and Personnel 

The trade-off between the crew-size requirements in the ORD and overall crew 
performance was the prime initiator of this thesis. Simply writing and approving a 
requirement for crew of set size is not enough. The crew-size requirement must be 
balanced with requirements in human factors engineering and overall human 
performance. A primary conclusion of the thesis is that by applying the proposed human- 
automation interface model to other functions in the vehicles, both in the CFM and in 
vehicle-specific function, it is possible to make further reductions in operators task¬ 
loading, and MWL. This will also support attempts to achieve the current ORD 
requirement for a vehicle operable by a 2-soldier crew. This work is intended to 
contribute to the effort to ensure that vehicle systems in the MGV fleet can accomplish 
the overall unit mission and the PCS’ mission as an acquisition program. 

However, further analysis using the Target Audience Description (TAD) may 
reveal that not just any soldier will be able to man a vehicle in the MGV fleet. It may 
prove much more difficult for a brand new soldier or lower-category soldier to efficiently 
and effectively operate these highly advanced crew stations across the MGV fleet. 
Rather, it will a soldier with more experience or more intelligence (i.e. higher test scores) 
to operate in the crew station with advanced automation schemes. 

An additional consideration is the range of military occupational specialties 
(MOS; see US Army Pamphlet 611-21) that will man the CCS of different vehicles in the 
MGV fleet. Infantry soldiers will be in the ICV, tankers in the MCS, medics in the MV, 
artillery soldiers in the NLOS-Cannon, various logistics and maintenance in the FRMV, 
etc. Each of these MOS has unique requirements for physical strength, medical status, 
and intelligence/aptitude. Yet, they will all be manning a similar CCS that may not take 
into account the differing personnel requirements of all the MOS called to man the crew 
station in the O&O plan. 
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2. Training 

Regardless of final design of the human-automation interaction scheme in the 
MGV fleet, it will be necessary to acquaint soldiers in training as to the exact nature of 
the resulting interaction between themselves as operators and the software/hardware 
automation. The extensive literature base available on human-automation performance 
makes it quite clear that humans and failures often occur when the operators simply do 
not understand what the automation is doing, best expressed when humans start asking: 
What is it doing now? What will it do next? Why did it do this?” (see Woods & Sarter, 
1998) 

As with the possible need for a higher category of soldier to man the MGV, the 
requisite amount of training in the CCS will likely increase. This is especially true if 
high levels of automation are introduced in some functions. The soldier-operators must 
be able to clearly understand what any automation scheme is doing ‘behind the scenes’, 
so to speak. They must have a succinct and accurate ‘mental model’ of the overall 
operation so that they are able to anticipate, troubleshoot, and even take over from the 
automated system when necessary. Simply believing that certain tasks and functions 
work ‘like magic’ is a recipe for human error and system failure, thus a degradation in 
system performance. 

A final item in training is the issue of soldier trust in automation. As a crewman 
and part of this total vehicle system, the soldier-operator’s trust in the automation is 
dependent on his familiarity with the automation scheme. This could demand longer 
training periods (in or out of the schoolhouse) and high fidelity training aids, devices, 
simulators, and simulations (TADSS). There are also accounts of operator misuse of 
automation, where excessive trust can lead operators to rely uncritically on automation 
without recognizing its limitations or fail to monitor the automation’s behavior 
(Parasuraman & Riley, 1997; see also Parasuraman & Miller, 2004; Lee & See, 2004). 

The increased training demands may be alleviated through well-conceived, 
human-centric embedded training, performance support systems, and job performance 
aids. 
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3. Human Factors Engineering 

This thesis has largely been a human factors engineering effort, but with 
definitive effects on other HSI/MANPRINT domains. The proposed qualitative model 
has a goal of not only defining the human role in the overall system, but also in keeping 
MWL at an acceptable level during the entire functional flow. It fosters improved human 
performance as part of the total vehicle system, in turn enhancing system effectiveness 
and suitability. IMPRINT is a good way to quantify the effects of task-loading, and is in 
extensive use already in the MGV program. 

4. System Safety and Soldier Survivability 

The potential impacts of this thesis are similar for the System Safety and Soldier 
Survivability (SSv) domains, though probably less effect. System safety experts normally 
conduct extensive Failure Modes Effects Analysis (FMEA) and Failure Modes Effect 
Criticality Analysis (FMECA) concurrently as a system moves from Milestone B towards 
Milestone C in the DoD systems acquisition process. The FMEA/FMECA efforts should 
be widened slightly to look at the interaction between hardware/software automation and 
the soldier-operators. Ignoring the interaction causes the FMEA/FMECA efforts to miss 
possible key points of system failure that may not be attributable directly to software, 
hardware, or human. 

The impact on SSv, similar to FMEA/FMECA, lies along the analysis of potential 
fratricide as a result of a breakdown or misinterpretation of the human-automation 
interaction scheme in the vehicles. Recommended automation levels allow sensors and 
software (automation) to be much more involved in the acquisition, analysis of target 
information than in the past, targets that may be friendly. Likewise, automation in the 
form of decision/action support may err and recommend action against a friendly target 
based on automated target assessment. SSv assessments using the US Army Research 
Lab’s PAL (Parameter Assessment List) should include checks on any possible fratricide 
potential caused by unexpected (or incorrect) human-automation interaction. 
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D. FURTHER ACTIONS 

Parasuraman et al. (2000) proposed both primary and secondary evaluative 
criteria that provide a good road map of further actions as the design of the MGV crew 
stations continue. In the primary evaluative criteria, this thesis was wholly focused on 
the MWL aspect, analytically predicting task-loading as a result of the crew station and it 
proposed human-automation interaction. Once simulations and prototypes are available 
for user demonstrations, it will prove useful to empirically evaluate mental workload via 
a variety of means (physiological, primary task, secondary tasks, or subjective rankings; 
see Gawron, 2000), and then look at the relationship between MWL and actual crew 
performance. 

Parasuraman et al. (2000) emphasize the importance of testing and evaluating 
preliminary choices of automation functionality. Iterative testing against the proposed 
primary and secondary evaluative criteria will establish the best automation levels for the 
system. Complacency, skill degradation, and the constructs of SA can be evaluated 
throughout the development testing and operational testing (DT/OT) schedules. 
Additionally, the proposed models in this thesis and the MGV crew stations are natural 
candidates for rapid prototyping and experimentation (see Moore, Kennedy, and Kern 
2003; Kennedy and Durbin, 2005 for examples). Use of these tools and techniques during 
the system design and development phase of the DoD acquisition process can be the 
primary ways to gather data on human performance (primary evaluative criteria). 

Finally, the entire FCS program is decisively moving from concept to reality. 
Further iterations of the systems engineering process will continue to further define and 
refine necessary the details of the MGV crew stations and the exact roles for soldiers as 
the operators and maintainers. Human factors engineers, manpower and personnel 
specialists, training designers, and safety, health and survivability analysts will be needed 
to round out a design team with other engineers of various backgrounds (software, 
electronics, mechanics, etc.). User groups and SMEs will also be necessary to evaluate 
and refine the design as the system takes form. 
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VII. CONCLUSIONS AND RECOMMENDATIONS 


This thesis provides human factors engineers, systems engineers, designers, and 
developers a top-down, overarching approach that enables them to explicitly define and 
design the interaction between proposed automation schemes and the human crew. In 
effect, it constitutes the design methodology and automation philosophy, as espoused by 
Rouse et al. (1987). A qualitative model was proposed to drive the functional architecture 
and human-automation interface scheme on the Army’s PCS manned vehicle fleet. The 
proposed model is applied to a portion of the functional flow of the MGV common crew 
station It is a logical approach to function decomposition with a reasonable paradigm to 
use to conceptualizing the shared roles between human and automation. With this tool in 
hand, the exact role of the Soldier operators as the central component of the vehicle 
systems can be more clearly understood before the fielding of the vehicle systems. The 
proposed model was then demonstrated quantitatively via a computational task-network 
modeling program (IMPRINT), to gain an understanding of the impacts on human task¬ 
loading, and therefore workload and human performance. 

Judicious application of the proposed qualitative model, coupled with quantitative 
analysis of the task-loading effects via IMPRINT, can be continued for other functions in 
the various MGV crew stations. This will further provide a guide to defining the 
relationship between human and automation and the resulting human performance 
ramifications. This is but one way (among several) to work toward the ORD requirement 
for a 2-soldier crew. But, even if the 2-soldier crew requirement is relaxed, a coherent 
plan for automation will help to ensure soldier performance and system effectiveness. 
The focus of the model is to ensure that a reduced-crew can perform well enough (not 
optimally) to accomplish all of the functions and tasks asked of the total vehicle system. 
If we eventually conclude that an additional crewmember is required on the various 
MGV vehicles, the same qualitative and quantitative models can be used to gain a clear 
understanding of the human-automation interaction as well as the some of the human 
performance ramifications in terms of mental workload. 
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While this thesis foeuses on ways to solve real technieal issues in the PCS MGV 
fleet, the model and analytieal proeesses proposed, or similar approaehes, eertainly are 
necessary in a wide array of complex systems in multiple domains (aviation, space, 
maritime, ground transportation, manufacturing, etc.). As a thorough literature review 
reveals, there are very few people thinking about an ‘automation philosophy’ to guide the 
complex interactions between humans and automation to ensure total system 
performance. So while the proposals here were developed for the PCS MGV fleet, they 
are in no way limited to that particular application. 
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APPENDIX. ADDITIONAL EXAMPLE OF THE MODEL IN 
ACTION - US NAVY’S LITTORAL COMBAT SHIP 


Included is the complete paper titled Developing a Human-Automation Interface 
Model of the Littoral Combat Ship’s Fire Control System. It was published in the 
proceedings of the 2005 Human Systems Integration Symposium held 20-22 June 2005 in 
Arlington, VA. 


75 



Joshua S. Kennedy, Jeffrey A. Thomas, and John M. Green 


Developing a Human-Automation Interface Model 
of the Littoral Combat Ship’s Fire Control System 


ABSTRACT 

This paper outlines how Human Systems 
Integration (HSI) methodology was used to 
design a fire control system for the U.S. Navy 
Littoral Combat Ship (LCS) as an example, 
with an emphasis on reductions in manning. 
The design team’s original objective was to 
design a control system for the main gun that 
could be operated by one person or less. 
Mission analysis of the LCS and its weapons 
systems generated possibilities for manning 
reduction that extend well beyond the ship’s 
main gun. The team’s application of HSI 
methodology gave rise to a ‘fire control 
system’ where the operator-automation team 
could accomplish the ship’s surface warfare as 
well as air self-defense missions with only one 
sailor. The team applied a model of human 
interaction-with-automation to outline the 
design methodology (Parasuraman, Sheridan, 
& Wickens, 2000). This approach also 
delineates several tradeoffs among HSI 
domains to be made in further iterations of the 
HSI process. In order to ensure optimal system 
performance, it is critical to implement HSI 
methodology for all complex systems 
requiring a human interface. 

INTRODUCTION 

In support of its Sea Power 21 strategic vision, 
the U.S. Navy is developing the Littoral 
Combat Ship (LCS) to deliver focused mission 
capabilities to enable joint and combined 
forces the capability of defeating the 
conventional and asymmetric access-denial 
threat in the littoral area (U.S. Navy PEO 
Ships, 2004). 

The littoral area of control extends from the 
open ocean, to the shore, and to those inland 
areas that can be attacked, supported and 


defended directly from the sea. The LCS will 
defeat enemy littoral defenses including 
mines, fast swarming small boats, and 
submarines, ultimately ensuring maritime 
access in any environment (see figure 1). 
“Working together as part of a netted 
distributed force, this future fleet will project 
power forward and enable naval and joint task 
force commanders to dominate the littoral 
battlespace” (US Navy, 2004). 



Figure 1 Artist Conception of Littoral 
Battlespace 


Mission Analysis 

This project was a course requirement for 
SI4001 (Systems Integration and Architecture) 
as part of the new HSI Masters of Applied 
Science program at the Naval Postgraduate 
School (NPS), CA. The professor is the third 
author. In the beginning of the course, he 
issued this directive: “Design a control system 
for the LCS guns that can be operated by one 
person or less”. Our team understood this to 
be a primitive need statement that supports 
minimal manning and provided a starting 
point for the analysis process. 

At first glance, we were tempted to use the 
traditional approach of applying only human 
factors engineering design concepts to design 
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a computer display for the LCS gun system. 
However, since it is closely related to systems 
engineering (SE), the HSI process must begin 
with a thorough understanding of the U.S. 
Department of Defense and the U.S. Navy’s 
needed capabilities (requirements analysis). 
Three Navy lieutenants and four Army 
civilians conducted background research into 
the LCS and various gun systems to identify 
capability gaps between legacy gun systems 
and the intended capabilities of the LCS gun 
system. We derived an accepted gun system 
designed from the user’s perspective to enable 
and enhance the LCS capabilities in the 
littoral. 

The LCS Flight 0 Interim Requirements 
Document (IRD) was the primary reference 
document (US Navy 2003). The LCS focused 
mission capabilities are mine warfare (MIW), 
littoral surface warfare (SUW) against small, 
highly armed boats, and littoral anti-submarine 
warfare (ASW). Its inherent mission 
capabilities include joint littoral mobility, 
maritime interdiction/interception operations, 
homeland defense, and others. In addition, to 
support its focused and inherent mission area, 
it must also have core capabilities for air self 
defense (ASD), survivability, aviation support, 
logistics, and others. Based on the IRD, the 
gun control system for the LCS must help 
enable the LCS to achieve these capabilities— 
and do it with one operator or less. 

Going from a ^^Gun Control System” to 
a “Fire Control System” 

Mission analysis of the LCS and its weapons 
systems generated possibilities for manning 
reduction that extended well beyond the ship’s 
main gun. The team’s application of HSI 
methodology gave rise to a ‘fire control 
system’ where the operator-automation team 
could accomplish the ship’s surface warfare as 
well as air self-defense missions with only one 
sailor. The system is made up of not only the 
hardware and software, but also the humans 
that must operate, maintain, and support it. 

The human element of the system will 


ultimately affect its operational effectiveness 
and suitability. 

After gaining an understanding of the LCS 
missions and what the gun control system 
must support, we began to ask some questions: 

Ql) What exactly are the targets of the gun 
system? 

Al) The naval officers on the team said it 
would be the surface threat of multiple small 
boats. 

Q2) Will the gun system ever shoot at an 
aerial threat, like a threat aircraft or an anti¬ 
ship cruise missile (ASCM) as per the ASD 
capability? 

A2) No. Other systems on the LCS address the 
aerial threat. For example, the MK 15 Phalanx 
Close-In Weapons System (CIWS) can be 
used against ASCM, the SM-2 Standard 
Missile SM-2 can be used against threat 
aircraft, and the RIM-7 Sea Sparrow missile 
against either. 

Q3) Will the CIWS, SM-2, or RIM-7 ever be 
used against surface threats? 

A3) No, they are strictly for ASD. 

Q4) What does the gun system do during 
MIW and ASW? 

A4) Nothing, there are other weapons systems 
used for those missions. 

So then we asked ourselves the crucial 
question: Can we have one operator control 
the weapons for both SUW and ASD? At this 
point in the process, we hatched the idea to 
band together these mission capabilities under 
a single operator. Of course, this concept is 
easier conceived than realized, so the rest of 
this paper portrays our application of HSI 
methodologies while working on this idea. 

Consequently, our proposal is more than a gun 
system—it is an integration of the SUW and 
ASD weapons systems into a fire control 
system (PCS) that can be run by one sailor. 
This PCS will integrate the gun system to 
support the SUW focused mission capability, 
plus any combination of CIWS, SM-2 and 
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RIM7 to help achieve the ASD capability 
(both ASCM and threat aircraft. Figure 2 
shows a graphic representation of our 
proposal. 

The mission statement of this fire control 
system will be to enable the LCS to effectively 
deliver primary and inherent mission 
capabilities in the littoral. It shall be operated 
by one person or less. It shall integrate and use 
the common tactical picture (CTP) to detect, 
track, engage, and destroy targets. Its primary 
objective will be to conduct SUW and ASD 
independently or as part of a carrier strike 
group (CSG) or expeditionary strike group 
(ESG). 



Figure 2. Proposed Fire Control System 


Assumptions 

To begin setting up a functional flow for the 
FCS and its automation, we had to make 
several assumptions. First, any control system 
on the LCS will be based on the threat posture 
of the ship, typically determined by the ship’s 
commanding officer or higher authority. To 
begin the design, we designated three postures 
similar to (in order of severity): WHITE, 
YELLOW, and RED. The color codes are 
also used as air defense warnings by the U.S. 
Department of Defense (DoD) to denote 
degree of air raid probability. In our system, 
WHITE means attack by hostile forces is 
improbable, YELLOW means attack by 


hostile forces is probable, and RED means 
attack by hostile forces is imminent or is in 
progress. This threat posture will determine 
the level of FCS automation in use, and 
represents the first time a human interfaces 
with the overall system. 

As a necessity to begin the functional flow, we 
also assumed high trust, due to reliable 
automation. This assumption will be 
rigorously evaluated during its life cycle, but 
further design is very difficult without it. 

Lastly, we assume that a high threat 
environment equals a high mental workload 
environment. If there are multiple surface and 
aerial targets to detect, track, identify, and 
engage, then the operator’s mental workload 
(MWL) will be appreciably higher. The ship 
will likely be at threat posture RED. 
Conversely, a low threat environment equals a 
low mental workload environment (i.e. threat 
posture WHITE). 

Functional Flow 

As shown in figure 3, the FCS functional flow 
has six major functions that are iteratively 
performed for each new contact: 

1. Search for contacts 

2. Detect 

3. Track 

4. Classify 

5. Resolve 

6. Shoot 

Most of these functions are self-explanatory, 
but two of them need further definition. Step 
4, Classify, is where the FCS determines if the 
target is a threat or not. Since the FCS is 
made up of hardware, software, and humans, 
this function may be carried out by any 
combination of these components, depending 
on the automation design. Step 5, Resolve, has 
a dual meaning. In this stage, the system 
seeks to gain greater resolution on the target, 
acquiring more information to help decide 
whether to attack it or not. This stage is also 
about resolving to destroy or not. Classify and 
Resolve are functions where the system will 
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have to make multiple decisions prior to 
carrying out an action (Step 6, Shoot). 



Figure 3. FCS Functional Flow (Level 1) 


Figures 4 and 5 show a more detailed 
functional flow, with multiple subfunctions 
under the six primary functions. 


Figure 4. FCS Functional Flow (Level 
2 ) 

HUMAN-IN-THE-LOOP 

We have mentioned the FCS’ automation 
several times, and that this automation must 
allow one operator to control weapons to 
support both the SUW and ASD missions. 
The critical question to be answered at this 
point is where and how the operator will 
interface with the automation in the 
functional flow of this system? 


To answer this question, we needed an 
operator-in-the-loop paradigm. 

We found such a paradigm in Parasuraman, 
Sheridan, and Wickens (2000), whose model 
is the foundation of our automation design 
process. Their model, for types and levels of 
automation, provides a framework for 
deciding what aspects of the system should 
be automated and to what extent. 

Appropriate selection of automation levels is 
important because “automation does not 
merely supplant but changes human activity 
and can impose new coordination demands 
on the human operator” (2000). Automation 
can vary across a continuum of levels, from 
the lowest level of fully manual control to 
the highest level of full automation. Table 1 
shows a proposed 10-point scale, with 
higher levels representing increased 
autonomy of computer over human action 
(2000). For example, at a low level 2, 
several options are provided to the human, 
but the system has no further say in which 
decision is chosen. At level 6, the system 
automation gives the human only a limited 
time to override before carrying out the 
decision. 
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Figure 5. FCS Functional Flow (Level 2) (continued) 


Table 1. Levels of Automation of 
Decision and Action Selection 
(Parasuraman et al, 2000) 

HIGH 10. The computer decides everything, acts 
autonomously, ignoring the human 
9. Informs the human only if it, the 
computer, decides to 
8. Informs the human only if asked 
7. Executes automatically, then 
necessarily informs the human 
6. Allows the human a restricted time to 
veto before automatic execution 
5. Executes the suggestion if the human 
approves 

4. Suggests one alternative 
3. Narrows the selection down to a few 
2. The computer offers a complete set of 
decision/action alternatives 
LOW 1. The computer offers no assistance; 

human must take all decisions and 
actions 



Figure 6. Levels of Automation for 
independent functions of information 
acquisition, information analysis, 
decision selection, and action 
implementation. Examples of systems 
with different levels of automation 
across functional dimensions are also 
shown (Pararsuraman et al, 2000) 


Using their model, we developed an 
automation scheme for the FCS. In Figure 7, 
instead of presenting system alternatives for 


Parasuraman et al (2000) proposed that 
automation can be applied to four broad 
classes of functions as shown in Figure 6. 
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analysis, we propose three possible levels of 
automation based on the LCS’ threat posture 
(RED, YELLOW, or WHITE). As per our 
main assumption, a higher threat level 
(RED) means a higher level of human 
MWL, so we propose a higher level of 
automation across the four broad classes. 
Conversely, a low threat level (WHITE) 
means a lower level of MWL. In the first 
two stages (Acquisition and Analysis), there 
are high levels of automation in all three 
postures. The human operator is largely a 
supervisor in the Acquisition stage, 
presented with information only: the status 
of SUW and ASD weapons, status of 
various LCS sensors (radar, sonar, etc.), and 
status of the common tactical picture with 
other ships, vehicles, and aerial/space 
platforms, among other options. Likewise, 
in the Analysis stage the automation 
presents the operator information about 
targets detected, including characteristics of 
the target (bearing, speed, altitude) and the 
symbology assigned by the ECS. 



Figure 7. First stage automation 
scheme for FCS. 


The human operator takes a more active role 
between the Analysis and Decision stages as 
defined by the ship’s threat posture, which 
in turn defines the level of automation in 
use. In the WHITE posture, the human 
might have more authority over FCS 
decisions to be made and total control over 


the action to be taken. In the RED posture 
(high threat, high MWL), the automation 
might have more autonomy and the human 
would presumably only have authority to 
override the action the FCS is about to take. 
The YELLOW posture might take a level of 
automation between WHITE and RED. 

We also note that the four broad functions of 
Parasuraman et al. are analogous to the 
Observe-Orient-Decide-Act (OODA) loop 
commonly used by DoD personnel across all 
U.S. military Services. 

Next, we applied our functional flow to the 
proposed automation scheme, replacing the 
four broad functions with the six major FCS 
functions (see figure 8). Search replaces 
Acquisition; Detect and Track replaces 
Analysis; Classify and Resolve replaces 
Decision, and Shoot replaces Action. Again, 
the three possible levels of automation are 
RED, YELLOW, and WHITE. For the 
Search, Detect, and Track functions, we 
reasoned that a high level of automation is 
warranted. The FCS, using the ship’s sensor 
and the CTP, will search, detect and track all 
targets, then present real-time and concise 
information to the operator about those 
targets, as well as the status of SUW and 
ASD weapons, sensors, and common tactical 
picture. 



Figure 8. Proposed Automation 
Scheme for the LCS Fire Control 
System 
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The Classify and Resolve functions 
(replacing Decision) is present four major 
decisions that the system (both software 
and/or human operator) must make. 

1. What is the classification of 

the target? Is it a threat? 

2. What is the priority target? 

What should the PCS shoot at first? 

3. Which weapon to use 

against that target? 

4. Shoot or not shoot? 

One major value of this automation proposal 
based on the Parasuraman et al. model is 
that system designers can fine-tune the 
levels of automation at each of the vertical 
lines in the diagram. You can simply 
modify the level of automation as you might 
move the slider bars up and down much in 
the same way of slider bars on a stereo 
equalizer, thereby achieving the balance 
between human and software that the system 
designers and engineers desire. 

In the WHITE posture, due to the assumed 
low threat level and low operator MWL, we 
propose that the operator interacts more 
fully with the software. In the first decision, 
the PCS automation classifies the target and 
makes a recommendation to the operator, 
who can then confirm the classification or 
countermand the recommendation. This 
would be similar to level 4 or 5 in table 1. 
Continuing through the functional flow, the 
automation may then present a single 
recommendation for the highest priority 
target (level 3 or 4). When choosing the 
appropriate weapon system, automation 
level rises back up to level 4/5 (makes 
recommendation, then executes if operator 
approves). Since the optimal weapon to use 
against the selected target is entirely a 
function of target characteristics (surface vs. 
air, then ASCM vs. aircraft), we believe the 
automation would make a better and faster 
decision recommendation than the human. 
The final decision, to shoot or not, is left 
entirely to the human; the automation offers 
no assistance. In this regard, at the WHITE 
posture, the human operator will be under 


absolutely no pressure or suggestions to ‘pull 
the trigger’—he will be able to make that 
decision unfettered by any recommendations 
from the software. Lastly, the actual act of 
actuating the chosen weapon is left entirely to 
the operator (who at this point is probably 
under supervision from a more senior officer) 
with no input from the PCS automation. 

In the YELLOW posture, in response to the 
higher threat level, we can simply move up 
the slider bars on selected decisions to allow 
the system to achieve more efficient 
performance while probably allowing an 
intermediate level of operator MWL. 
Decisions 1-3 might remain at level 4/5, but 
the automation will be allowed greater 
autonomy (and thus influence) in Decision 4 
by actually recommending to shoot at (or not 
shoot at) the target with the selected weapon 
system. However, as with the WHITE 
posture, the final action is left entirely to the 
operator (and possibly his higher 
supervisors). 

In the RED posture, due to the assumed high 
threat level and to help alleviate the likely 
high MWL of the operator, we propose that 
the software maintain a higher degree of 
autonomy throughout the Classify and 
Resolve functions, probably similar to level 7 
as per table 1 (software decides 
automatically, then informs the human; 
human can step and override the automation). 
Unlike the other two threat levels, we 
propose that in RED, the automation has 
much greater autonomy, being allowed to 
execute the action unless the operator 
overrides the action. This kind of autonomy 
may likely well be warranted in high threat 
environment with multiple surface and air 
threats. In addition, but noted in figure 8, is 
the possibility of having the PCS makes a 
steering recommendation for the ship, or 
even steer the ship itself (though this 
possibility may be controversial). This kind 
of design decision would have to be decided 
at the highest levels of the ECS program 
leadership with input from users and subject 
matter experts. 
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Decision 

Red 

Yellow 

White 

Threat? 

FCS decides, 

Operator must 
override 

FCS recommends. 
Operator confirms 

FCS recommends. 
Operator confirms 

Priority? 

FCS decides, 

Operator must 
override 

FCS recommends one 
target. Operator 
confirms 

FCS gives range of 
choices. Operator 
decides 

Weapon? 

FCS decides. 

Operator must 
override 

FCS recommends. 
Operator confirms 

FCS recommends. 
Operator confirms 

Shoot? 

FCS decides. 

Operator must 
override 

FCS recommends. 
Operator confirms 

Operator decides, no 
input from FCS 

Action-Shoot 

FCS shoots. Operator 
must override 

Operator shoots 

Operator shoots 


Table 2. Operator-Automation 
Interaction at Key Decision Points 


Table 2 summarizes the proposed levels of 
automation for each function and the major 
decision points. Again, these levels are 
proposals based on team discussions with 
several subject matter experts (SMEs). The 
value of the Parasuraman et al. model is that 
further discussions within various working 
groups (WG) and integrated products teams 
(IPT), based on experience or other 
empirical research, can easily fine-tune the 
automation levels as necessary. Of course, 
there is also the possibility of adding or 
removing functions or decisions from the 
functional flow and subsequently the 
automation scheme as depicted in figure 8. 

In figures 9-11, we present the latter half our 
PCS functional flow (figure 5) for each of 
the three threat postures. The four major 
decisions in the Classify and Resolve 
functions (denoted by stars) have generally 
increasing levels of automation as threat 
posture goes from WHITE, YELLOW, and 
then RED in response to the operational and 
intelligence situation. The former half of the 
functional flow is not presented since we 
proposed that automation levels remain the 
same in the Search, Detect, and Track 
functions for each of the three threat 
postures. 



Figure 9. FCS Functional Flow at 
threat posture WHITE. The four key 
decisions (stars) and the action are 
spotlighted. 

HSI DOMAINS— 
IMPLICATIONS AND 
TRADEOFFS 

The proposed FCS and its automation scheme 
has major impacts on multiple HSI domains, 
and we have identified a number of tradeoffs 
that need resolving should the system 
continue design and development. 

Manpower, Personnel, and Training 
(MPT) 

The zero-based manning concept drove this 
design from the beginning, and if the FCS 
concept is brought to fruition, we stand to 
merge manpower from three or four different 
weapon systems into one fire control system 
operator 

In addition, though not discussed in this 
paper, there is the possibility of incorporating 
certain electronic warfare (EW) into the 
automation scheme under the same operator. 
Of course, all this assumes well-designed and 
reliable automation. 

As a tradeoff for the possible manpower 
savings, this automation scheme will require 
increased development cost and time from 
systems software engineering. Most 
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acquisition officials would probably 
characterize it as a high-risk effort in terms 
program cost, performance, and schedule. 



Figure 10. FCS Functional Flow at 
Threat Posture YELLOW. Levels of 
automation of slightly higher for 
Decisions 1-3 



Figure 11. FCS Functional Flow at 
Threat Posture RED. Level of 
Automation higher for All Decisions 
and the Action 

An additional tradeoff will be in the 
Personnel domain, as the knowledge, skills 
and abilities needed to operate this system 
may require higher aptitudes than current or 
legacy technology. It may not be possible 
for new sailor or lower-category sailor to 
operate this system; rather, it may take an 
experienced and intelligent petty officer or 


junior officer to operate the FCS as proposed. 

Likewise, the requisite amount of training to 
operate this proposed FCS will increase. As 
part of this system, the operator’s trust in the 
proposed FCS automation is highly 
dependent upon his familiarity with the 
automation scheme driving the FCS. This 
will demand longer training periods and high 
fidelity training aid, devices, simulators, and 
simulations (TADSS). It also points out the 
probable need, based on training needs 
analysis, for a stand-along TADSS off-ship, 
as well as onboard scenarios built into the 
FCS. However, the increased training 
demand may be alleviated through well- 
conceived embedded training, performance 
support systems, and job performance aids. 

Human Factors Engineering 

We have an implicit goal of keeping operator 
MWL at an acceptable level during the entire 
functional flow across all possible threat 
postures. This is to foster improved human 
performance as part of the system, in turn 
improving overall system effectiveness and 
suitability. HSI practitioners can build a 
comprehensive workload model to assess 
whether MWL is kept at reasonable levels 
throughout the functional flow at different 
threat levels. For example, the Improved 
Performance Research Integration Tool 
(IMPRINT) from the US Army Research Lab 
(ARL) is a well-documented and widely-used 
tool, particularly for human performance in 
military applications (see the IMPRINT 
website at: http://www.arl.army.mil/ ARL- 
Directorates/HRED/imb/imprint/ 
Imprint7.htm. 

FURTHER ACTIONS 

Evaluative Criteria 

Automation is not an all-or-none affair; 
rather, it can vary by type. In the 
Parasuraman et al. model, and as used by our 
team, human interaction with automation can 
be applied to any or all of a system’s 
functional flow at the level required to gain 
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optimal system performance. Parasuraman 
et al. (2000) argue that 

any particular level of automation 
should be evaluated by examining its 
associated human performance 
consequences. These constitute the 
primary evaluative criteria for levels of 
automation. However, human 
performance criteria is not the only 
important factor. Secondary evaluative 
criteria include automation reliability 
and the costs of decision/action 
consequences. 

Automation can have both beneficial and 
negative effects on human performance. 
There are four human performance areas 
that should be included in the primary 
evaluate criteria of this PCS: mental 
workload, situation awareness, 
complacency, and skill degradation (2000). 
Evidence suggests that well-designed 
information automation can change MWL to 
a level that is appropriate for the systems 
tasks being performed. However, “clumsy” 
automation can lead to increasing workload. 
As mentioned above in the HFE 
implications, MWL can be modeled during 
system design to assess if it is reasonable 
throughout system functional flow. 

Besides unbalanced MWL, automation can 
incur human performance costs in the other 
three criteria suggested. Situation awareness 
can be negatively affected when the 
operators loses “awareness of the system 
and certain dynamic features of the work 
environment” (2000). If the PCS automation 
is highly but not perfectly reliable in 
executing the major decision choices, “then 
the operators may not monitor the 
automation and its information sources and 
hence fail to detect the occasional times 
when then automation fails” (2000) or is 
wrong. Complacency is greatest in high 
MWL setting when the operator is engaged 
in multiple tasks. Third, skill degradation 
can certainly occur over time if the system 
decisions are routinely carried out by the 
automation. “These potential costs— 


reduced situation awareness, complacency, 
and skill degradation—collectively 
demonstrate that high-level automation can 
lead to operators exhibiting out-of-the-loop 
unfamiliarity. All three sources of 
vulnerability may pose a threat to safety in 
the system failure” (2000). The FCS 
automation design must demonstrate that 
potential human performance costs, along 
with unbalanced MWL, do not occur. “By 
considering these human performance 
consequences, the relative merits of a specific 
level of automation can be determined” 
( 2000 ). 

Secondary evaluative criteria can include 
automation reliability and the cost of decision 
and action outcomes. Reliability is typically 
defined in probabilistic terms, such as a 
reliability of .997 or a mean time to failure of 
10,000 hours. In addition, “failures may 
occur not because of a predictable (in a 
statistical sense) malfunction in software or 
hardware, but because the assumptions that 
are modeled in the automation by the 
designer are not met in a given operational 
situation” (2000). The reliability of 
automation also influences human trust, 
possibly undermining potential system 
performance benefits when the automation is 
underused or disabled. In addition to 
reliability, “assessing the appropriate level of 
automation for decisions requires additional 
consideration of the costs associated with 
decision and action outcomes” (2000). 

Incorporating Prior Research, Rapid 
Prototyping and Experimentation 

Our decisions on the type and level of 
automation throughout our functional flow 
was determined by team discussions, input 
from locally available SMEs, and our own 
reasoning, all with the goal of improved 
human performance in the resulting system 
(primary evaluative criteria). Additionally, 
there is the possibility of incorporating prior 
research into these decisions on the 
appropriate type and level. For example, prior 
research may have shown that compared to 
manual operations, both human and system 
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performance are enhanced by level 4 
automation but degraded by automation 
above level 6 (2000). Based on this research, 
we apply the finding at the appropriate place 
in the framework. In lieu of prior research, 
performance modeling may provide similar 
guidelines. 

Parasuraman et al. (2000) emphasize the 
importance of testing and evaluating 
preliminary choices of automation 
functionality. Iterative testing against the 
proposed primary and secondary evaluative 
criteria will establish the best automation 
levels for the system. Additionally, the 
proposed PCS and it automation is a natural 
candidate for rapid prototyping and 
experimentation (see Moore, Kennedy, and 
Kern 2003; Kennedy and Durbin, 2005 for 
examples). Use of these tools and techniques 
during the system design and development 
phase of the DoD acquisition process can be 
the primary ways to gather data on human 
performance (primary evaluative criteria). 

Finally, the proposed FCS is still very much 
a concept. Further iterations of the SE 
process will be required to further define 
and refine necessary capabilities and 
operational requirements as part of the LCS. 
Human factors engineers and MPT 
specialists will be needed to round out a 
design team with other engineers of various 
backgrounds (software, electronics, etc.). 
User groups and SMEs will also be 
necessary to evaluated and refine the design 
as the system takes shape. 

CONCLUSION 

The LCS is designed to fight and win the 
world’s littoral area, but it must do so with 
significantly less manning than historically 
used on our ships. The zero-based manning 
concept and the constraint of a single 
operator likely requires the increased use of 
automation. Automation design is both art 
and science, and can be guided by the model 
presented by Parasuraman et al. Given the 


primitive need, our team judiciously applied 
and modified the model in order to design an 
FCS with an automation scheme that allows 
one operator to control the weapons systems 
for both the SUW and ASD mission of the 
LCS. Judicious application of the 
Parasuraman et al. model in other programs 
may help achieve reduced manning without 
sacrificing human and system performance. 
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